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ABSTRACT 

A  battle  group  commander's  successful  employment  of  the  assets  in  his 
battle  group  heavily  relies  on  his  conceptualization  of  the  pragmatic 
capabilities  of  each  of  these  assets.  This  thesis  comprises  an  inter- 
active decision  support  system  (DSS),  which  utilizes  database  manage- 
ment and  high  resolution  computer  graphics,  to  assist  the  commander  in 
meeting  this  challenge.  The  DSS  incorporates  data  on  specific  systems 
installed  on  each  unit  as  the  basis  for  user  developed  capability  effec- 
tiveness/system coverage  displays.  The  system  is  designed  to  be  opera- 
ted through  discrete  speech  voice  recognition  equipment. 
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I-     EACKGEOOND    AND    OVERVIEW 
1.       ANOTEER    DECISION    AID    !?       —    A    DEFENSE 


. ..      I   never    neaded  any    computer   to  make  a   decision    for 

me    our   success    just   gees   to  show  ycu   don't   need 

any   of   these    fancy   computer      sysxems  when  it  comes   right 
down   tc    trass    tacks. ..*" 


Six  months  into  development  of  a  thesis  which  was 
designing  a  computer  based  Decision  Support  System,  xhis 
statement   is  somewhat   provocative.  Recently,      this    au-hor 

sat  in  an  audience  captivated  by  the  dynamic  commander  who 
was    en   stag€.  A    pcrtion    of   his     closing   remarks   included 

the  paraphrase  which  headed  -his  chapter.  Was  the  connota- 
tion of  his  statement  more  than  his  egc-invclvement  spawned 
by   the   euphoric    taste  of  success? 

The  mandate  of  command  is  to  make  decisions  when  opera- 
tions "come  down  tc  brass  tacks."  There  is  no  such 
mandate  for  a  computer  system.  The  commander  who  doesn't 
avail  himself  of  all  sources  and  methods  of  display  of 
information  cannot  be  as  confident  of  his  decisions  as  the 
commander  who  does.  The  ccmplexity  of  cemtemporary  peace- 
time and  wartime  operations,  in  concert  with  technological 
advancements  which  are  cccuring  at  near  exponential  rates, 
is  cften  times  characterized  by  too  much  information  to 
digest,  however.  Computer  supported  decision  making  can 
overwhelm  and  often  dilute  human  capabilities  by  prolifer- 
ating the  volumes  of  knowledges  which  a  user  feels  compelled 
to  assimilate.  This  gives  rise  to  a  common  malady  in  the 
Military,    "decision    aid   angst." 

Originally,  computer  systems  focussed  on  abilities  to 
manage      massive        amounts      of      information,  a      Management 
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Information   System       (EIS).  Mors   recently,      the      focus   has 

shifted  to  translating  existing  technological  capabilities 
into    Decision   Support  Systems    (DSS)  .  The   DSS    channels   the 

massive  data  processing  capabilities  of  today's  computer 
technology  towards  the  "decision"  and  away  from  demon- 
strating how  much  data  can  be  manipulated.  DSS,  in  the 
purists'  view,  is  an  extension  of  the  innerwor Icings  of  the 
commander  himself.  The  commander  has  participated  in  its 
design,  and  it  then  allows  him  to  make  a  comprehensive  deci- 
sion based  on  inf ormation  organized  for  presentation  in  a 
format  he  desires.  Row  the  designer  of  the  DSS  defines  the 
user-system  interaction  requirements  as  well  as  the  format 
of  the  information  display,  becomes  the  difference  between 
whether  the  power  to  the  system  is  "on"  throughout  the  deci- 
sion   making   process,    cr   "off,"    archieved   for   "future   use." 

This  thesis  addresses  an  interactive  decision  support 
system  for  a  battle  group  commander,  to  enhance  the  effec- 
tive management  of  the  assets  assigned  to  the  battle  group. 
It  focusses  on  a  realistic  dialogue  [Ref.  1]  and  substantive 
information  representation  to  expand  its  useability  and  not 
dust    collecting    capability. 

B-       EECISICH    SUPPORT    SYSTEMS 

For  a  Decision  Support  System  to  have  long-term  utility, 
it  must  be  the  result  of  an  "evolutionary  "  design  process. 
This  process  must  address  both  the  evolution  of  the  tech- 
nology,   and   that  of    the    user. 

The  necessary  iterative  design  process  relies  on  short- 
term  feedback  between  the  user  and  the  developer  to  ensure 
that  required  change  is  implemented  in  the  short  terra. 
This  process  applies  to  the  three  fundamental  subsystems  of 
a  DSS,  dialogue,  data  management,  and  model  management. 
[Ref.    1] 
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This  thesis  addresses  a  specific  component  of  a  battle 
group  commander ■ s  sphere  of  responsibility,  asset  manage- 
ment. It  has  been  developed  based  on  this  author's  experi- 
ence in  Fleet  operations.1  As  the  designer  and  user  of  the 
CSS,  the  precepts  discussed  above,  fundamental  to  the  design 
cf  a  CSS,  have  been  met.  Extension  of  the  applicability  to 
follow-cn  user  groups  would  necessitate  "evolutionary"  fine 
tunirg    tc      each    group.  This    DSS      is    based  on    a      schema  of 

management  of  a  capatilities  database  of  a  designed  battle 
group,  and  translating  that  database  into  descriptive 
computer    graphics      displays.  Control        of    DSS      operations 

with  respect  to  user-system  interaction  represents  stata  of 
the  art  technology  in  the  utilization  cf  voice  recognition 
protccols.  With    the   use    of   voice,        the    user    is   thus    free 

from    the   confines  of   a  terminal    keyboard.  Ths    system,      as 

developed,  does  not  represent  a  stand  alone  DSS  in  the 
complete      sense    discussed      above.  The    "Model      Subsystem" 

[Ref-  1  ]  is  manifested  in  the  tactical  knowledges  cf  the 
user,  and     not        en     analytic        or      mathematical        mcdel. 

Incor pcraticn  of  such  a  model  or  models  is  an  obvious 
follow-or      enhancement      to      the        system.  Less      a      model 

subsystem,  a  semantic  title  of  "Decision  Support  Subsystem" 
may  be  contemplated,  however,  in  actuality,  this  system  does 
cperate  based  on  a  mcdel,  the  user.  The  "model"  which  this 
CSS  utilizes,  resides  in  the  mind,  experience,  and  fibre  of 
a  user,        which    has    been      hcned   throughout   a     career.  The 

cutgrcwth  cf  this  system  is  an  extension  of  the  commander's 
"mind's  eye,"  an  interface  between  the  conceptual  and  the 
real.  In      formulating  the   best      employment   of      his    battle 

group,    based  on    the    capability    (sensor   and    weapons)      of   each 


lIhe    author    has      participated   in    6    READIEX,         3    FLEETEX, 
and   numerous  other    warfare    exsrcisas.  This   experience   has 

included  functioning  as  a  principle  watchstander  for  the 
ASWC.  ASUKC,  or  AAWC  in  the  majority  of  these  operations, 
additionally,  the  author  has  attended  zhe  TACTRAGRUPAC  Staff 
Tactical   Training  Course. 
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ship  in  the  force,  this  DS  S  allows  the  commander  -c  extsr- 
nally  visualize  the  interplay  of  capabilities  among  these 
assets. 

C.       EIALCGOE   SOBSYSTEB    DEVELOPMENT 

Any  system  which  encompasses  a  man-machine  interaction 
must  strive  for  that  illusive  "symbiotic"  relationship  where 
iran  and  machine  are  in  harmonic  unison  with  each  ether. 
The  principle  stumbling  block  to  achievement  of  this  goal 
has  been  the  format  of  the  language  which  joins  the  two, 
English  versus  "Computerise. "  Additionally,  the  "angst" 
mentioned  earlier  can  be  an  outgrowth  of  a  deficiency  of 
clerical  skills  on  the  part  of  the  user,  at  the  interface. 
The  challenge  is  accentuated  by  the  speed  mismatches  between 
iran  and  machine  "thinking.  "  The  issue  is  to  construct  a 
common  language  at  the  interface,  where  the  goals  and  inten- 
tions of  the  user  are  easily  translated  into  the  logical 
courses   cf    action   of   the  computer.      [Raf.    2] 

Can      a    computer      really      be      friendly?  This      question 

should  mere  accurately  replace  "computer"  with  "compu-er 
software    designer."  Therein   lies      the   source      of    many     of 

today's   misgivings.  The    software   designer    must    be   attuned 

to  the  real  world  requirements  and  not  just  code  formats  or 
primitives.  If  the  designer  looks  at  the  man-machine  envi- 
ronment, and  accurately  interprets  it,  then  computers  can 
indeed  be  "friendly."  Users,  by  their  human  nature,  have 
expectations.  Therefore,      a      computer      system    should      be 

predictatle.  The      adversarial   relationship      which      could 

develop  tetween  man  and  machine  is  eliminated  when  the  use- 
is  given  responses  frcm  the  system  which  reinforce  a  confi- 
dence that  the  information  is  "shared,"  and  not  one  sided. 
This  relationship  is  further  cultivated  by  the  system 
returning   positive   feedback      to   the    user    when     a    response   is 
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entered,    a   stop-gap    fcr   potential  anxiety.  When   all    these 

concepts  are  merged,  the  key  which  unlocks  the  puzzle  points 
to    "vocabulary. "      [ Ref .    3] 

This  DSS  has  taken  into  account  the  vernacular  of  the 
tattle  group  and  interfaced  it  with  the  vocabulary  of  the 
computer.  Soing    one  step    further,    the   input   medium,      with 

voice  recognition,  has  allcwed  tha  evolution  of  the  inputs 
intc   a   conversational  and  not   command    format.  Flexibility 

has  been  incorporated  into  the  formats  by  allowing  multiple 
options  fcr  each  component  of  a  conversational  construct. 
Therefore,  consistency  is  met  while  concurrently  allcwing 
flexibility  to  meet  the  user's  multiple  needs.  Internal  to 
the  system,  this  practice  neves  one  step  further  with 
cemmenly  used  conversational  inputs  grouped  into  single  wcrd 
inputs,    when  feasible. 

Finally,  the  value  of  operating  the  system  through  voice 
control   cannot    be  overstated.  Not   only    ioes  this   interac- 

tive format  free  the  user  from  translation  of  his  thought 
processes  through  a  keyboard,  but  also  provides  mobility 
throughout  the  work  center  or  watch  station,  while  main- 
taining control  of  the  system.  The  pragmatics  of  the 
conversational  interactions  in  this  DSS,  while  accomodating 
multiple  options,  nearly  exhausts  the  256  utterance  vocabu- 
lary of  this  discrete  speech  equipment  (Threshold 
Technology's  T-600).  However,  while  the  obvious  extension 
is  to  convert  the  DSS  to  a  connected  speech  technology,  when 
properly  trained,  the  T-600  has  shown  remarkable  ability  to 
discriminate  utterances    and    handle    the    demand. 

C.       EISI€N    PHILOSOPHY 

There  were  three  principle  design  philosophies  which  the 
author    adhered      to    in      developing   this      DSS.  First,         the 

system   is      survi vable,        or    in    another      parlance,       "robust. " 


The  query/response  sequences  are  all  supported  by  system 
error  checks  to  preclude  unintentional  "bombing"  of  the 
system,      and     reduce   user      apprehension.  Each      view    which 

requires  a  user  response  shows  examples  of  correct 
responses.  The   differences   between      the   entry    formats    for 

keyboard  and  voice  are  illustrated,  in  detail,  in  the  User's 
Manual,      the  third   chapter    of   this   thesis.  In    addition   to 

providing  as  error  check  cf  the  inputs,  the  language  is 
simple  and  replicates  how  the  user  would  normally  articulate 
the    parameter   being    addressed.  Additionally,      the   User's 

Manual  shows  example  sequences  through  a  complete  session 
with  the  system,  reproducing  the  logical  inputs  and  system 
responses,      as    well    as      error   recovery   features.  Finally, 

the  DSS  is  consistent,  in  that  the  types  of  entries  and 
their  respective  results  are  identical  throughout  the  eight 
modules    cf    the   systeir. 

E.       GBAPHICS   —    IMPBCVIHG    PERCEPTION    OF    CAPABILITIES 

The      "acid   test"      of  the      performance    cf      any    sensor     or 
weapcns    system    is   in   actual    operations.  When   these   opera- 

tions are  with  an  adversary,  whether  in  an  exercise  or  real 
world,  the  preparatory  thought  given  to  -che  employment  of 
those  assets  significantly  impacts  on  their  aggregate 
performance.  In    assimilating      the    huge      amounts    of      data 

required  to  make  a  credible  decision  as  to  asset  employment, 
timeliness  requires  the  commander  digest  that  information  in 
"chunks."  The  results  of  numerous  studies  have  borne  cut 
that  visual  perception  of  large  amounts  cf  information 
significantly  increases  human  ability  to  draw  inferences  and 
make    subsequent    judgements.  The    same    graphics    display    may 

represent  differing  interpretations  to  different  pacple. 
However,  the  "evolutionary"  design  process  of  a  DSS, 
precludes      this      eventuality      by   having      had      the      commander 
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provide  the  input  as  to  the  design  of  the  displays,  and 
thereby  the  format  of  the  information  represented.  [Ref.  4] 
The  graphics  capabilities  of  this  DSS  reflect  state  of 
the  art  graphics  technology.  The  applications  programs  for 
the  displays  are  written  utilizing  the  DI-3000  software 
language.  The      only   shortfall   of      the   hardware    in      use  is 

that  it  dees  not  allow  complete  filling  of  overlapping  poly- 
gons (principally  circles  in  this  case)  on  the  same  view. 
This  reduces  the  effectiveness  of  the  overall  sensor/weapons 
coverage  displays  by  having  multiple  circles  shown  vice  one 
solid  area  for  force  coverage.  The  bottom  line,  though,  is 
that  the  graphics  displays,  regardless  of  this  shortfall, 
enhance  by  several  orders  of  magnitude  the  value  to  the 
force  of  radar  "a"  cr  weapon  "b,"  in  comparing  their  net 
effectiveness.  This  comparison  is  presented  in  relaticn  to 
the  ether  comparable  systems  in  the  force  to  provide  a 
comprehensive,    "net"   effectiveness    display. 

J.       ASSET    MANAGEMENT    DECISION    SUPPORT    SYSTEM 

This  thesis  is  organized  into  three  chapters;  an  intro- 
duction, a  discussicn  of  the  software  development,  and 
finally,  a  comprehensive  Usar's  Manual  for  operation  of  the 
system.  It  is  essential  to  pcint  out  at  this  juncture,  the 
design  has  attempted  to  maximize  the  ease  with  which  a  user 
interacts  with  the  system,  and  therefore,  the  User's  Manual 
can  assuire  a  more  appropriate  application  as  a  reference 
rather  than    a      mandatcry    prerequisite    for    operation. 

The  battle  group  assets  addressed  in  this  DSS  are  these 
commonly  found  in  a  carrier  or  surface  battle  group,  with 
their   supporting  Service  Force    ships.  In   the    interest   of 

econcny,  fcr  a  carrier  battle  group,  only  fighter  and  AEW 
airwing    assets    are    censidered.  The   general   functioning   of 

the    CSS      is    initiated      with    the      input   of      the  names      of    the 
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ships  which  will  compose  the  battle  group.  The  ship  names, 
in  turn,  are  the  key  elements  of  database  records,  which  are 
reflective  cf  that  ship's  sensor,  weapons,  and  UHF/HF  commu^ 
nicaticns  capabilities.  To  afford  maximum  dissemination  of 
not  cnly  this  thesis,  but  also  the  DSS  concept,  the  ship 
databases  have  teen  developed  from  unclassified  sourcss. 
However,  the  design  of  the  files  containing  the  data, 
readily    facilitates    the  transition   to   a   classified   database. 

The  focus  of  this  DSS  is  to  afford  the  battle  group 
commander  a  vehicle  whereby  he  can  "build"  a  battle  group 
from  specific  units  with  their  specific  capabilities  and  not 
typical   class      capabilities.  Whether   it    be     a    theoretical 

formation  cf  a  group  of  representative  ship  types,  or  a 
composition  of  task  organized  units,  the  system  will  crga- 
r.ize  and  display  the  performance  capabilities  of  the 
sensors  and  weapons  which  are  organic  to  the  developed 
group.  The      operations  of   the      DSS   revolve      around    estab- 

lishing the  positions  of  the  ships  from  designated  "ZZ" 
position,  then  allowing  the  user  to  display  to  the  terminal 
screen  specified  weapcns  and  sensor  capabilities,  as  well  as 
displayirg  to  the  graphics  monitor  the  translation  cf  equip- 
ment capability  intc  coverage  or  effectiveness  areas  for 
each    asset.  A   distinction   is    made   here,      between    terminal 

screen  and  graphics  mcnitor,  as  the  system  can  accomodate 
two  categories  cf  installations;  those  with  a  graphics 
interface,  and  those  without.  While  the  design  encompasses 
a  full  graphics  display  capability,  with  the  terminal 
displays  providing  supplemental  views,  the  supplemental 
views  are  comprehensive  and  can  stand  alone  should  the  user 
have    nc      graphics  capability.  For   operation      of    the      DSS 

withcut  a  graphics  capability,  the  user  should  refer  to  the 
introductory  sections  of   the   User's    Manual. 

with  the  graphics  capability,  once  the  coverage  areas 
have    teen   displayed,      the   user   can      expand   the   detail   of   the 
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view  by  displaying  a  cartesian  coordinate  grid  ard/cr  an 
appropriate     threat    sector.  Additionally,         with    an      eye 

towards  projecting  the  tactical  impact  of  moving  a  unit,  the 
user  is  afforded  the  opportunity  to  manipulate  the  positions 
cf  the  force  units  and  observe  the  subsequent  change  in 
force    ser.scr  or    weapons   coverage   effectiveness. 

Mere  towards  the  administrative  aspects  of  battle  group 
operations,  the  Composite  Warfare  Commander  (CWC)  organiza- 
tion can  be  constructed,  managed,  and  char.gsd. 
Additionally,  a  real  time  view  of  the  composition  of  the 
varicus  circuits  in  the  battle  group  communications  plan  is 
available.  In  the  COMMS  module  of  "he  DSS,  the  communica- 
tions nets  can  be  displayed  with  the  participating  units,  as 
dictated  by  mission  area,  shown.  An  extension  of  the 
commuricatiens  views  is  a  comparison,  on  the  UHF  nets,  of 
the  units  who  are  out  of  UHF  cemm  range  with  the  Net  Control 
Station.  A  final  administrative  capability  of  the  system 
is  allowing  the  user  to  enter  explanatory  remarks  for  a 
unit,  to  be  included  in  that  units  database  for  future 
ace ess/ display . 

G.       FCILCS-CN    ENHANCEBENTS 

The  primary  goal  of  this  thesis  has  been  to  initially 
develop  an  interactive  Decision  Support  System,  controlled 
through  voice  technology,  which  facilitates  a  battle  group 
commander's   management     of    his   assets.  There      are   several 

enhancements  to  this  CSS  which  could  be  addressed  by  future 
efforts. 

•  Ccnversion    to  Connected    Speech    Voice    Technology 

•  Incorporation   of      SHARPS   and   IREPS   data      as    alternatives 
to   the   system   default  sensor   capabilities 
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•  Expansion  of  th€  database  and  display  capabilities  to 
allow  display  of  the  opposition  sensors  and  weapons  on 
the  same  view 

•  Conversion  of  tie  software  to  micro- computer/desk  top 
use 

•  Adaptation  of  the  DI-3000  "Pick"  function  allowing  iden- 
tification of  menitor  coordinates  from  a  "Byte  Board" 
device 

•  Incorporation  of  performance  models  which  would  drive 
the  positioning  cf  the  force  units 

•  Interface  with  a  wargame  to  allow  representation  of 
capability  displays  unique  to  the  composition  of  the 
battle  group  in  use 

•  Incorporation  of  mapping  libraries  to  allow  display  of 
capabilities  with  respect  to  a  specific  geographic  area 


23 


II.    DECISION    S DEPORT    SYSTEM    SOFTWARE    DEVELOP HE ST 

1.       INTBCDUCTION 

The  previous  chapter  discussed  the  rationale  for  the 
development  of  this  thesis,  as  well  as  structure ,  and  some 
cf  the  key  components  of  the  design  utilized.  This  chapter 
addresses  the  development  of  the  software  which  supports  the 
Decision   Support      System.  The      discussion   will      cover   the 

scherca  utilized  for  the  system,  definitions  of  common  system 
variables,  as  well  as  a  general  overview  of  the  construct  of 
the  system  modules.  It  is  intended  that  this  chapter  be 
utilized  in  concert  with  the  system  program  (not  attached  to 
this  paper)  ,  which  is  written  with  algorithmic  descriptions 
incorporated  into   each   program   unit. 

E.       FBCBIEM    FORMULATICH 

The  fundamental  challenge  of  this  thesis  was  to  develop 
a  functicnal  support  system  for  a  battle  group  commander. 
This  system  was  to  prcvide  for  the  display  of  specific  force 
databases,  as  well  as  be  capable  of  translation  of  certain 
capabilities  in  those  databases  into  discernible  computer 
graphics  displays.  Parallel   to   these   efforts,    development 

cf  a  functicnal  user  -  computer  dialogue  format  was  consid- 
ered essential.  In  short,  therefore,  this  thesis  addressed 
the  challenge  of  developing  an  interactive  computer  database 
management/computer  graphics  system,  which  was  "user 
friendly,"  and  incorporated  the  capabilities  of  today's 
tattle    groups. 
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C.  SOLUTION   STRUCTURE 

The  program  was  written  in  FORTRAN-77,  American  National 
Standard  (ANSI  X3.9-1978),  with  extensions  developed  by 
Digital  Eguipment  Corporation  (DEC)  [Ref.  5]  for  execution 
en   a    VAX    11   or    PDP-11  series   computer.  Additionally,      the 

DI-3000  graphics  language  is  utilized  for  the  graphics 
unique   capabilities    cf  the    system.  The   control    medium   for 

this  system  accomodates  commands  from  the  terminal  keyboard, 
as  well  as  commands  entered  through  discrete  speech  voice 
recognition   equipments.  The      Threshold    Technology^    T-600 

was    the    -wcice   input    device    for   this    program.  However,    any 

compatible      equipment      could   be      utilized.  The      graphics 

cutput  was  generated  on  RAMTEK  high-resolution  graphics 
interfaces    and    monitors. 

D.  PBOGEAH  GENERAL  SCHEHA 

For    the     ease   of      software    design      and    program      testing, 
this    system     was   designed  around      the   construction      cf    eight 
(8)         major   modules.  With     the      exception   of      the      "MAIN 

Module,"  each  module  comprises  an  assamblege  of  subroutines 
which  focuses  on  the  features  incorporated  in  that  module. 
In  cases  where  a  subroutine  is  required  by  more  than  three 
(3)  sections  of  the  program,  that  subroutine  was  included  in 
a  general  section,  at  the  end  of  the  program.  As  an  exten- 
sion of  the  program  itself,  succeeding  topics  in  this 
section    will  address    the   design      of   each    module    group.  In 

addition,  a  glossary,  by  block  common  designations,  will  be 
provided  to    facilitate    following   the    flow    of    the    program. 

E-       SIGNIFICAHT    ADJUSTHEHTS 

There  were  five  principle  areas  which  were  cumbersome  in 
the  development  cf  this  program.  They  are  enumerated  below 
with    mention  of    the    vehicles    by    which   they    were   overcome. 
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a.   Management  of  the  Databases 

There  were  four  databases  developed  fcr  this 
system.  The  first,  the  Master  Database,  contained  coded 
capabilities  for  130  Pacific  Fleet  units,  with  seme  addi- 
tions to  provide  AEGIS  assets.  This  database  was  oriented 
around  the  name  of  a  particular  ship.  The  database  would 
be  utilized  by  the  user,  in  identifying  the  name  of  a  battle 
group  unit,  and  the  system  locating  the  record  associated 
with  that  ship  and  reading  the  record.  For  ease  of  manage- 
ment, an  indexed- keyed  access  format  was  utilized  for  this 
file.  The  primary  key  field  was  the  name  of  the  ship. 
The  secondary  key  fields  were  the  first  two  and  first  three, 
respectively,  characters  of  the  unit's  hull  designation. 
The  secondary  keys  were  so  devised  to  enable  distinction 
between  guided  missile  equipped  units  and  those  which  were 
not.  The  DEC  extensions  which  address  these  capabilities 
are  discussed  below. 

The  second  database  was  incorporated  into  the 
system  to  allow  the  user  to  use  the  short  form  name  of  a 
Ship,  for  example,  "FCSTER"  for  "PAUL  F  FOSTER,"  or  "CONNIE" 
for  "CONSTELLATION."  This  distinction  was  important,  as  the 
master  database  utilized  the  full  name  of  the  included 
ships.  This  database  file  was  also  formatted  in  a  keyed 
indexed  manner. 

The  third  database  was  actually  a  group  of  three 
files  which  contained  the  database  elements  for  the  partic- 
ular tattle  group,  which  were  developed  by  the  user.  These 
files  used  a  sequential  access  method. 

Finally,  the  communications  circuits  in  the 
battle  group  COMM  plan  were  stored  in  a  seperate  database  or 
file.  The  composition  of  this  file  was,  again,  a  keyed 
indexed  organization,  based  en  a  primary  key  of  circuit  ID 
numbers.  The  file  contained  the  ID,  circuit  name, 
frequency  range,  and  net  control  station. 


26 


0 )      Indexed/Keyed  Organization  Access . 

Eecords  in  an  indexed  file  are  ordered  by  the  fields  of 
those  record  elements  designated  as  key  fields.  This  orga- 
nization, then,  specifies  the  order  of  processing  of  the 
records  in  the  file.  You  must  specify  the  locations  within 
the  records  of  the  primary  key  field  (mandatory) ,  and  any 
alternate  key  fields.  Once  the  record  corresponding  to  the 
identified  key  has  teen  located,  this  organization  type 
allows  sequential  access  to  succeeding  records  in  that  file 
if   desired.     [Ref.    5:   pp.   7-3   to   7-5] 

t.      Correction      of        a      Capability      in        the      Master 
Database 

There  were  foreseeable  situations  where  a  change 
in  a  unit's  capability  was  to  be  incorporated  into  the 
Master      Eatabase.  This      eventuality      is   accomodated,        by 

allowing   manual      input  of      the   change      in    capability.  In 

order  to  adjust  the  Master  Database  to  reflect  this  change, 
a  REWBITE    feature   was  utilized. 

(1)       REWBITE  a    Eecord   in    a    Indexed/Keyed    File. 
The      BEWBITE  feature      transfers      output      data   from      internal 
storage    into  the      current   record    in   an      indexed    file.  You 

must  first  locate  the  record  you  desire  to  change,  with  a 
BEAD  statement,  then  REWRITE  will  update  the  record  as  you 
have    indicated.  In  this      program,      only    FORMATTED   REWRITE 

statements  were  utilized,  indicating  that  the  record  had  a 
specific  format  associated  with  the  data  entries.  [Ref.  5: 
P-    7-37] 

c.      Conversion  of      Ship    Name      into    Graphics      Integer 
Form 

Unique  to  the  DI-3000  graphics  language,  the 
text    prinitives    displayed   on   the      monitor   are   required    to   be 
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in  inter nal/integer  form.  The  difficulty  arose  when  the 
ship's  tames,  which  were  CHARACTER*19  variables,  were 
required  to  be  displayed  along  with  the  force  capabilities. 
The  necessary  conversion  of  these  character  variables  to 
internal  form  was  accomplished  through  the  use  of  the  DECODE 
extension. 

(1)       DECCDE   Operations.  The    DECODE      statement 

allows  the  conversion  of  character  variables  into  internal 
(binary)  form  according  tc  a  specified  format  statement. 
For  display  to  the  graphics  monitor,  the  names  of  the  ships 
were  transformed  frcm  their  character  form,  and  segmented 
into  a  five  element  integer  array  which  was  the  useable  form 
for   display.     [ Ref .    5:   pp.    A-1   to  A-2  ] 

d.      Segmenting   a   Multi-Element  Command  String 

In  several  of  the  display  modules,  the  number  of 
available  options  reguired  the  system  to  be  able  to  discrim- 
inate the  key  portions  of  multi-element  commands.  An 
example  of  this  requirement  is  reflected  in  the  command 
string  "DISPLAY  UNIT  KIMITZ."  Each  component  of  this  three 
element  command  was  selected  from  several  options.  These 
options  additionally  were  of  differing  lengths.  The 
system,  therefore,  had  tc  break  the  command  into  these 
components.  The  command  was  read  into  the  system  as  a 
thirty-four  (34)  element  integer  array,  and  through  the  use 
of  the  ENCODE  extension,  the  program  converted  each  of  the 
appropriate  command  elements  into  their  proper  character 
formats. 

O)  ENCODE  Operations.  The  functioning  of  the 
ENCODE  extension  is  identical  to  that  of  the  DECODE  func- 
tion, only  in  reverse.  The  integer  command  string  was 
first  broken  into  segments,  with  the  position  of  the  spaces 
indicating    a     new   element.  Next,         each    of      these   integer 
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segments  was  transformed  into  character  form  according  to 
the  format  required  for  the  particular  command  element. 
[Bef.    5:    pp.   A-1   to    1-2] 

1  •      Orientation    of   Ship    Names   on    Graphics   Plot 

Depending  on  the  scale  in  use  when  the  graphics 
capabilities  of  the  system  were  utilized,  a  great  deal  of 
clutter  reduced  the  effectiveness  of  the  display.  This  was 
predominately  due  to  the  congestion  involving  ship  names  in 
close  proximity.  This  clutter  was  reduced  by  orienting  the 
name  of  the  ship  comirensura  te  with  its  relative  position  in 
the      display.  The      subroutine    "ORIENT,"      to   be      discussed 

later,  made  a  comparison  of  the  position  of  the  unit  to  be 
displayed,  with  respect  to  the  plot  quadrant  it  was  in. 
Eased  en  th€  result  of  this  comparison,  the  DI-3000  "JJUST" 
call  was  controlled  to  reduce  the  numbers  of  overlapping 
names.  The    function      of    the      "JJUST"      subroutine    in      the 

EI-3000  language  is  to  orient  the  display  of  text  at  the 
position   specified.  The      call    to   this   routine      will    cause 

the  text  to  be  "justified"  at  its  center,  left,  or  right 
sides,  as  well  as  with  respect  to  the  top  or  bottom  of  the 
letters    in    the   text. 

J.       DSS    IILE   COMPOSITION 

This  Decision  Support  System  resides  in  the  Wargaming 
Analysis  and  Wargaming  Laboratory  (WABLAB)  at  the  Naval 
Postgraduate  School.  The  user  name  under  which  it  is  oper- 
ated is  called  "DECISION."  Should  this  user  account  not  be 
available  on-line,  the  complete  system  is  available  on  tape 
in   the    Lab.  The    main    program,    ooject,    and  execution    files 

all      have      the      "DSS"      name      associated      with      them.  The 

following  files  support  the  operations  of  the  system  and  are 
organic   to   this    account. 
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•  FCB011.EAT   This  file   contains  the  master  database 

for  the  DSS.  The  database  is  a  formatted,  keyed  access 
file  as  discussed  above.  It  is  from  this  file  that  the 
program  will  automatically  locate  the  database  for  the 
ship  identified,  and  transfer  that  data  into  the  battle 
group  operating  databases. 

•  f CB012. CAT   This   file  is  a  keyed   access  formatted 

file  which  contains  the  short  form  names  of  some  of  the 
ships  in  the  master  database.  When  the  system  searches 
the  Master  Database  to  extract  the  capabilities  of  a 
unit,  should  a  name  match  not  occur  in  this  search,  the 
system  will  first  check  this  file  for  a  short  form  name 
match  and  conversion  to  the  full  form  name,  before  the 
unit  will  be  "flagged"  for  manual  database  entry. 

•  gCR0C7. EAT  This  file  is  created  through  the  func- 
tioning of  the  system.  A  "SAVE"  capability,  allows  the 
user  to  store  the  data  which  he/she  has  developed,  and 
terminate  the  session,  resuming  it  at  a  later  time. 
This  file  is  seguentially  organized  and  contains  control 
variables,  number  of  ships  in  the  battle  group  and  their 
names.  It  is  used,  when  the  user  next  initiates  a 
session  with  the  system,  to  reaffirm  that  a  battle  group 
had  been  formed  previously. 

•  FCBQC8. DAT   This  file  is   also  generated   when  the 

"SAVE"  feature  is  exercised.  In  addition  to  the  names 
of  the  units,  as  was  available  in  FOR007.DAT,  this  file 
also  contains  the  complete  database  for  the  units 
designed  into  the  particular  battle  group.  This  is 
what  is  referred  to  in  the  system  as  the  "battle  group 
database."  It  is  read  into  the  system,  and  is  orga- 
nized through  the  use  of  linked  lists.  A  representa- 
tive record  in  this  file   is  more  comprehensive  than  its 
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counterpart  in  tie  master  database.  This  database  will 
reflect  current  capabilities,  as  well  as  user  generated 
information  as  tc  unit  position,  explanatory  remarks, 
etc.        This    file   is   sequentially   organized. 

•  FCB009. EAT      This    is      the   third      file  generated      by 

exercising      the    "SAVE"      feature      of      the   system.  The 

Ccmpcsite  Warfare  Commander  organization  is  stored  here. 
The  contents  of  this  file  are  the  names  of  the  warfare 
commanders/coordinators,  the  respective  organizations 
functioning  in  these  capacities,  and  the  unit  en  which 
the    respective   commander/coordinator    is   embarked.  The 

file   is   sequentially   organized. 

•  FCB0 19. DAT      The  communications      plan  structure      is 

ccrtained  in   this     resident    file.  As   with      the   master 

database  (FOR01  1  .EAT) ,  this  file  is  referenced  from  the 
CCBMS  Module,  however,  the  information  contained  therein 
is   net    transferred   to   DSS    for    manipulation.  This   file 

has  a  keyed  indexed  organization  based  on  the  primary 
key  of  circuit  IE  number.  The  remainder  of  each  record 
certains  the  name  of  the  net,  the  net  control  station, 
the  frequency  range,  and  the  applicable  mission  area  for 
which    this   net    is  used. 

G.       EICCK    COHMON    VARIABLE    DEFINITIONS 

In  an  effort  to  minimize  the  necessity  for  passing  large 
numbers  of  variables  between  using  subroutines,  extensive 
use  was  trade  of  "Block  Common"  constructions.  These  blocks 
grouped  those  variables  whose  use  was  similar,  and  whose 
data  type  was  the  sane.  As  a  reference  to  be  utilized  when 
reading  the  program,  the  following  sections  address  each  of 
these  blocks  and  define  the  variables  which  are  contained 
therein.  It    is  not   the   intent,      however,      that    a    complete 
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discussd.cn      of    the      range      of      possible   variable      values      be 
included.  For   a    comprehensive   review      of   the    values    which 

the    variables  could    assume,      reference   should   be    made   to   the 
User's    Manual,       chapter     three   of   this   thesis.  The    array 

dimension      cf   the      particular    variable      is      shown    in      paren- 
theses. 

a.  BDAT1    NOMSHP,  FIBST,  FREE,  LINK(25) 

This  block  groups  the  basic  integer  data 
regarding  the  organization  of  the  battle  group  database. 
The  definitions  of  the  variables  contained  in  this  block  are 
as    fellows. 

•  KUMSHF      Number   of    ships    in   the    battle   group 

•  fIBST     Head€r   for    the      battle   group   database   linked 

list 

•  EREE      The    first  available      record   position      in   the 

battle    group   database 

•  LINK      Battle   group    database    link    values 

b.  BDAT2       HULL  (25),     UNIT  (25)  ,     REMARKS  (25) 

This  blcck  contains  the  complement  to  the 
integer  tase  data  for  the  battle  group  database,  the  base 
character    variables.  The   definitions   of      these    variables 

are    as    fcllcws. 

•  HULI  —  A  *6  variable  representing  the  hull  number  of 
the    ship 

•  CNIT  —  A  *19  variable  representing  the  name  of  the 
ship 

•  BEM5RKS  --  A  *25  variable  of  a  general  nature,  input 
ty  the  user  as  descriptive  remarks  about  the  respective 
ship 
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C.   P0SIT1   COSYS,  ZZ  QUAD(25) 

This  block  organizes  one  of  the  two  positioning 
variable  groups,  and  represents  the  character  variables 
involved  with  the  ship  positions.  There  is  an  additional 
position  blcck  which  is  unigue  to  graphics  displays  and  is 
addressed  seperately.  The  following  is  the  composition  of 
this  tlcck. 

•  COSYS  —  A  *5  variable   indicating  the  type  of  coordi- 
nate system  in  use  (polar  or  cartesian) 

•  ZZ   —  A  *19  variable  indicating   tThe  name  of  the  unit 
at  "ZZ" 

•  COAD   —  A  *1  variable  indicating  the  position  quadrant 
of  a  unit  (implies  cartesian  positions  are  being  used) 

d.   POSIT2    XPOS(25)  ,    YPOS(25),    BRNG  (25)  , 

RNG  (25)  ,  SPEED (25) 

This  blcck  coirplements  the  previous  variable 
grouping  with  the  integer  variables  associated  with  the 
positioning  of  the  ships-  The  composition  of  the  block  is 
as  fellows. 

•  XPOS   —  The  position  of  the   ship  in  the  "x"  direction 
(implies  the  use  of  cartesian  coordinate  system) 

•  YPOS   —   The  position  of  a   ship  in  the   "y"  direction 
(implies  the  use  of  cartesian  coordinate  system) 

•  ESNG   —  Th€   bearing  of  a  ship  from   "ZZ"  (implies  the 
use  cf  the  polar  coordinate  system) 

•  BNG  —  The  ranee  of  a   ship  from  "ZZ"  (implies  the  use 
cf  the  polar  coordinate  system) 


•       SPESD 


The    maximum    speed    of    a   ship 
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€-       ADMIN1  CRUDES  (25),    DESRON(25) 

This  blcck  includes  the  character  variables 
which  represent  the  elements  of  the  administrative  organiza- 
tion cf  a  unit#s  database.  The  composition  of  this  fclcck 
is    as    fellows, 

•  CRODES  —  The  cruiser  destroyer  or  carrier  group  to 
which   a   ship   is    assigned 

•  DESBON  --  The  destroyer  sguadron  to  which  a  ship  is 
assigned  (not  applicable  to  aircraft  carriers  or  service 
force    ships) 

f,  ADMIN2  PRMAR(25),    SCMAR(25) 

This  block  contains  the  primary  and  secondary 
mission  areas  of  a  ship.  These  are  character  variables. 
The  composition  cf  the  block  is  as  follows. 

•  ERMAR  —  A  *3  variable  representing  the  primary 
mission  of  a  ship 

•  SCMAR  —  A  *3  variable  representing  the  secondary 
mission  of  a  ship 

g.  SCHRDR         SBSCH(25),     ARSCHA(25),     ARSCHE  (25) 

This  block  represents  the  search  radars  in  the 
database.  These  are  integer  variables,  and  the  composition 
cf    the    blcck  is    as    fellows. 

•  SRSCH  —  The  variable  representing  the  surface  search 
radar   onboard  a    ship 

•  ABSCHA  —  The  variable  representing  the  primary  air 
search    radar  onboard  a    ship 

•  ARSCHE  --  The  variable  representing  the  secondary  air 
search    radar    (as    applicable)    onboard   a   ship 
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h.       WEAPN1  PHAL(25),       GUN  (25),:         MYSLA  (25)  , 

MSLB(25) 

The    parameters      cf   the      weapons   capabilities     of 
the    database     are   represented      in   this      block.  These      are 

integer    variables,      and     the   composition   of  the      block    is   as 
follows. 

•  PHAI      —   The   number  of    PHALANX   systems   onboard    a   ship 

•  GUN        —   The      variable      representing      the  type      of      gun 
system   cnboard   a    ship 

•  MYSLA     —    The   variable    representing   the   type    of   primary 
missile   system    (as   applicable)    onboard   a   ship 

•  MYSLB     —    The   variable    representing      the   type    of    secon- 
dary missile  system    (as    applicable)     onboard   a    ship 

i.       WEAPN2         HARP  (25),    TOMA(25),    SLO  (25) 

This      blcck     contains        the      character      variable 
complement   of   the    weapons  block   above.  The   composition   cf 

this    block    is   as   follows, 

•  HARE      —   A    *1    variable     (Y/N)       indicating   whether    a   ship 
has    a    HARPOON   capability 

•  SOMA      —   A    *1    variable     (Y/N)       indicating   whether    s   ship 
has    a   TOMAHAWK    capability 

•  SLQ     —  A    *1    variable       (Y/N)      indicating   whether   a  ship 
has    an    AN/SLQ-32    capability. 

j.       WPNRDR         FCRA(25),    FCRB  (25) 

The    fire    control      radar   capability  of    a      ship    is 
represented   in      this    block.  These   are      integer   variables, 

and    the    composition    cf  the    block    is    as    follows. 

•  PCRA        —    The      variable   representing      the   primary      fire 
ccntiol   radar    (as  applicable)    onboard   a   ship 
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•  FCRE   —  The  variable  representing  the  secondary  fire 
control  radar  (as  applicable)  onboard  a  ship 

k.   COMM      SAT(25)  ,      UHF(25),     HF  (25)  , 

UHFAVL(25),  HFAVL(25) 

This  block  contains  the  communications  capabili- 
ties cf  the  ships  in  the  battle  group.  These  are  integer 
variables,  and  with  the  exception  of  the  SAT  variable, 
represent  the  actual  number  of  equipments.  The  composition 
of  this    block   is   as    fellows. 

•  SAT      --  The     variable    indicating   the    type      of    satellite 
communications   capability    (as   applicable)    onboard   a   ship 

•  DHI      —     The   nuirter   of      UHF    radios   installed      onboard   a 
ship 

•  KF      —   The    number   of   HF   radios   installed   onboard    a   ship 

•  CHFAVL     --    The    number    of    UHF   radios    available   onboard   a 
ship 

•  HF      —    The    number  of   HF   radios    available   onboard    a   ship 

1.       SENASW  IVDS(25),    TASS  (25)  ,    SONAR  (25) 

This  block  contains  integer  variables  repre- 
senting the  types  of  ASW  sensors  available  in  the  battle 
group.        The  composition  of    the   block    is  as   fellows. 

•  IVDS      —      The    type      of    IVES      equipment    (as      applicable) 
onboard   a  ship 

•  TASS      —      The   type      of    TASS      equipment    (as      applicable) 
onboard   a   ship 

•  SONAR      —    The    type    of      sonar    (as   applicable)       onboard   a 
ship 
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0.       WPNASW1  ASWFOC(25) 

This  bl cck  represents  the  character  variable 
indicating  the  type  cf  ASW  rccket  onboard  a  ship,  as  appli- 
cable. The  representation  of  this  variable  is  "A"  for 
ASROC,    "£"    for    SUBROC,    or    "  N"    for    NOT   CAPABLE. 

n.       WPNASW2         TOEE(25) 

This  block  contains  the  integer  variable  repre- 
sentation cf  the  type  cf  torpedo  onboard  a  ship.  The 
composition  of  the  variable  is  "1"  for  MK-46,  "2"  for  MK-48, 
cr    "0"    fcr    NOT    CAPABLE. 

c.       AIRCAP         HELC(25),     EMB(25) 

This  block  addresses  the  aircraft  capability  of 
the  tattle  group  with  respect  tc  type  of  helicopters  avail- 
able within  the  force.  The  composition  of  this  block  is  as 
follows. 

•  HELO  --  A  *1  variable  indicating  the  type  of  helicopter 
capability    a  ship   has  onbcard 

•  EKB  —  A  *1  variable  (Y/N)  indicating  the  eratarcatior 
status    of   a    ship    which    is    helicopter   capable 

p.       COMAND  CMD(8),    ORG  (8)  ,     EMBARK  (8) 

This  block  contains  the  composition  of  the  CWC 
Organization.  The  representations  of  these  character  vari- 
ables   are   as  follows. 

•  CMD  —  A  *5  variable  representing  the  name  of  a  warfare 
ccmmander/cocrdinator  --  this  value  is  fixed  in  the 
EIOCK   DATA    section   of  the    program 

•  ORG  --  A  *25  variable  representing  the  name  of  the 
organization  functioning  as  a  warfare  commander/ 
coordinator 
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•  EMEABK  —  A  *19  variable  indicating  the  name  cf  the 
ship  on  which  the  warfare  commander/coordinator  is 
eirbarked 

q.       RAMI  ORD(37),         ABS(37),       SCALE,  SIZEr 

CHAR_SHIE 

This  blcck  contains  real  variables  which  are 
utilized   in     the   graphics  portions      of   the      program.  They 

relate    tc   the      graphics   plot   parameters   associated      with   the 
display   capability    of  this    DSS.  With   the   exception   of   the 

ORD    and    ABS   variables,      these   values      are    fixed   in   the    ELOCK 
EATA      section   of      the   program.  The      composition   of      this 

cemmen   blcck  is    as    fellows. 

•  GEE  —  Plot  "x"  position  cf  a  ship  or  display  feature 
(1-25   --   ships,    26-35   --   ship   temporary    positions,    36-37 

—  AEW/CAP    features) 

•  ORD      —   Plot      "y"  position   of   a   ship      of   display    feature 

(1-25   --  ships,    26-35   --    ship   temporary   positions,    36-37 

—  AIW/CAP    features) 

•  SCALE  —  The  scale  (1-5)  controlling  the  dimensions  of 
the    display    coverage 

•  SIZE  --  A  scaling  factor  applied  to  displayed  graphics 
text  primitives  used  tc  maintain  balance  with  the  plot 
dimensions 

•  CHAR_SHIP  --  A  control  variable  used  as  the  basis  for 
the  siza  of  the  ship  name  text  primitives  displayed  on 
the   screen 

r.       BASP0S1  EASCUAD 

This  blcck  contains  the  character  variable 
representing  the  quadrant  in  which  the  ship  functioning  as 
"ZZ    is    positioned.  The   variable    is    utilized   in    the   compu- 
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tatior  cf  the  graphics  equivalent  positions  of  the  remainder 
cf   the    ships  in    the    tattle    group. 

S.       BASPOS2         BASORD,    BASABS,    POSX,     POSY 

This  block  contains  the  integer  (BASORD  ,BASAES) 
and  real  (ECSX,  EOSY)  variables  which  are  utilized  tc  orient 
the    graphics  plot  to    the   position   of   the    "ZZ"    ship.  It   is 

also  used  in  computing  the  required  offset  for  the  display 
of  the  cartesian  coordinate  grid,  an  option  in  the  graphics 
portions   of   the      DSS.  The   composition   of  the      block    is   as 

follows. 

•  BASOED      —    The    "x"   position   of   the   ship   at   "ZZ" 

•  EflSAES      —    The   "y"    positicn   of   the    ship  at   "ZZ" 

•  PCSX     —  The   graphics   plot    "x"   coordinate   for    the   origin 
cf   tte    cartesian    grid  display 

•  PCSY     —  The   graphics   plot      "y"   coordinate  of   the   origin 
of   tte    cartesian    grid   display 

t.       VIRTUAL         LEFT,       RIGHT,       UP,       DOWN,       LPORT, 

RPORT,    UECRT,    DECRT 

This  blcck  contains  the  parameters  associated 
with  the  definition  of  the  graphics  display  plot.  They  are 
tied  tc  the  DI-3000  inputs  addressing  the  WIN  DO  size  and  the 
VIEWPORT   size.  These   are    real      variables    and  their    values 

are    fixed    in     the   BLCCK    DATA   section   of      the    program.  The 

compcsiticn  of    the    blcck  is    as   follows. 

•  LIIT     The    left    dimensional      limit   for  the      WINDO  of 

the    graphics   display 

•  RIGHT      —   The      right  dimensional    limit    for      the    WINDO   of 
the    graphics   display 
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•  OF      —    The    upper   dimensional    limit      for   the    WINDO   of   the 
graphics  display 

•  DCWN     --     The   lower   dimensional      limit    for  the      WINEO   of 
the    graphics  display 

•  LPORT      —  The  left  dimensional   limit    for   the    VIEWPORT   of 
the    craphics   display 

•  RPORT      — «   The      right   dimensional   limit    for      the    VIEWPORT 
of   the    graphics    display 

•  OEORT      —  The   upper   dimensional   limit    of   the    VIEWPORT   of 
the    craphics  display 

•  DPORT      —   The      lcwer  dimensional    limit    for      the    VIEWPORT 
cf   the    graphics    display 

H,       MCDOIE    COMPOSITICB    AND    CAPABILITIES 

The  following  sections  of  the  chapter  will  address  the 
general  composition  and  capability  of  each  of  the  modules  in 
this    program.  Within  the   discussion      of   each      module,      a 

brief  description  of  the  purpose  of  each  subroutine  within 
that  module  will  be  presented.  This  section  is  intended  to 
be    utilized   in    conjunction    with   the    DSS    computer    program. 

1  .      WAIN  Module 

The  MAIN  module  is  the   program  unit  which  serves  as 
the  substructure  upon  which  the  remainder  of   the  system  is 
formed.    The  module  is  oriented  around  a  BLOCK  I?  construc- 
tion which  discriminates  among   the  options  (system  modules) 
presented. 

The  BUILD  module  of  this   program  allows  the  user  to 
tuiid  a  local  battle  group   database  composed  of  ships  which 
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the    user   designates.  Additionally,      this   module    functions 

as  the  point  from  which  the  user  can  INSERT  or  DELETE  a  shi? 
from  the  battle  group.  The  BUILD  subroutine  will  differen- 
tiate between  the  user's  desires  to  develop  the  datatase  for 
an  entire  force,  or  lake  individual  changes  to  an  existing 
structure,  through  the  use  LOGICAL  IE  and  BLOCK  IF  construc- 
tions. There  are  two  parameters  which  are  required  by  the 
BUILD  subroutine.  The  first  (SEXIST),  is  a  logical  vari- 
able which  flags  the  existarce  of  a  current  battle  group 
database.  The  second  (FIESTC),  is  again,  a  logical  vari- 
able which  is  changed  in  the  subroutine  to  indicate  that 
this  module  has  been  called.  The  system  requires  that  this 
module  te  called  prior  to  operations  in  any  other  module 
with  the  exception  of  the  DATAEASE  module,  discussed  later. 
Within  the  EUILD  Module,  the  numbers  and  names  of  the  battle 
group  ships,  as  well  as  their  positions  are  determined. 
Ihe  search  for  the  ship  record  in  a  master  database  is 
accomplished  through  the  SEARCH  subroutine,  organic  to  this 
nodule.  BUILD  will  also  call  the  MANUAL  subroutine, 
utilized  for  manual  input  of  a  ship1  s  database  if  the  ship 
cannct  be  located  in  the  master  database.  Finally,  from 
this  module,  the  CWC  organization  can  be  developed  through 
the    use    of    the    CWC    sutroutine,    organic    to    the    BUILD    module. 

a.      Position    Subroutine 

This  subroutine  is  utilized  by  several  of  the 
system  modules  to  input,  change,  and  display  the  positions 
of   the      ships   in   the    force.  There   are    four      entry    points 

into  this  subroutine,  controlled  by  a  COMPUTED  GOTO 
construction.  These   entry    points,    specified   by   the    param- 

eter "TAEGET"  are  BUILD  module  battle  group  Initialization 
(1)  ,  BUILD  module  IKSERT  function  (2),  STATUS  module  (3), 
and    SENSCR      module     (U).  This    subroutine      allows    for      the 

specification   of  coordinate    system,    polar   or   cartesian,      and 
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the    position     identification   cf   each      ship.  Additionally, 

this  subroutine  develops  the  basic  parameters  upon  which  the 
graphics      coordinate   system      is      computed.  This   is      done 

through  the  use  of  the  PLOTP  (polar)  or  PLOTC  (cartesian) 
subroutines   in    the    SENSOR   module. 

t.      CWC    Subroutine 

This  subroutine  allows  for  the  initial  estab- 
lishment of  the  CWC  organization  as  well  as  future  display 
cr   component     changes.  The    design      of   this      subroutine   is 

oriented  around  two  CCMPDTED  GOTO  constructions.  The  first 
differentiates  between  which  module  called  the  subroutine, 
Euild  module  CWC  organization  initialization  (1),  STATUS 
module  Display  cpticn  (2)  ,  or  the  STATUS  module  Change 
option       (3) .  The      second      COMPUTED      GOTO   construction      is 

utilized  tc  orchestrate  movement  through  the  components  of 
the  eight  (8)  warfare  commanders/coordinators  in  the  organi- 
zation. A  key  feature  in  the  operations  of  this  subroutine 
is  the  elimination  cf  redundancy  in  the  identification  of 
organizations  and  embarked  units.  The  prcgram  will  attempt 
to  match  an  input  the  user  makes  to  any  of  those  already 
input.  When      a   match     occurs,      say      in   the      naming    of     an 

embarked  unit,  the  program  assumes  the  value  will  remain  as 
previously  specified  and  will  not  query  the  user  tc  repeat 
the    input. 

c.      SEARCH    Subroutine 

This  subroutine  will  search  the  master  database 
(FOR0  11.EAT)  for  the  records  associated  with  the  named 
ships,  and  extract  the  appropriate  record.  This  subroutine 
will  also  use  the  MATCH  subroutine  to  allow  the  user  to 
input  a  short  form  name  for  ship,  convert  it  to  long  form, 
and   reinitiate   the   search. 
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d.      MATCH  Subroutine 

This  subroutine  will  attempt  to  match  a  short 
form    name   of  a    ship    through    the   use   of   file   FOR012.DAT. 

3  .      ST A 1US    Module 

Ihe  STATUS  module  in  the  Decision  Support  System 
allows  the  user  to  change  an  element  in  a  particular  ship*s 
database  record,  change  force  positions,  or  change  an 
element  of  the  CWC  organization.  Additionally,  this  module 
provides  the  vehicle  whereby  the  user  can  display  tc  the 
terminal  screen,  the  positions  of  the  force,  as  well  as  the 
names  of  the  units  with  specific  weapons  capabilities. 
This  module  is  designed  to  operate  without  the  use  of 
computer  graphics.  The  functioning  of  this  module  is 
oriented  around  the  interpretation  of  a  thirty  four  (34) 
character  command  string,  which  is  segmented  through  the  use 
of  the  ENCODE  fortran  extension,  discussed  earlier.  Each 
command  string  is  broken  into  three  character  variables 
which  respectively  address,  the  major  module  options,  data- 
base component  to  which  this  option  is  to  be  applied,  and 
finally,  the  display  or  category  specifier.  Once  the 
command  string  has  been  broken  into  the  appropriate 
segments,  the  module  utilizes  BLOCK  I?  constructions  to 
discriminate  between  the  various  segments.  The  STATUS 
subroutine  comprises  the  largest  portion  of  this  module. 

a.   DISDAT  Subroutine 

Organic  tc  the  STATUS  module,  the  DISDAT  subrou- 
tine provides  the  framework  upon  which  the  specific  equip- 
ment names  and  associated  ranges  are  translated  from  the 
codes  utilized  in  the  program  databases.  The  operations  of 
this  subroutine  are  oriented  around  two  general  groupings  of 
COMPUTED   GOTO   constructions.     The   first   differentiates 
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between  the  calling  subroutines  and  directs  program  func- 
tions in  either  an  equipment  display  or  nomenclature/range 
display    direction.  While   this   subroutine      is    principally 

used  ty  the  STATUS  module,  it  does  provide  the  terminal 
screen  displays  of  specific  equipments  utilized  by  the 
SENSOB    and    WEAPONS    modules. 

4  .      CC « KS    Module 

Ihe  communications  module  is  designed  to  accomplish 
two      objectives.  lie      first      function      is   to      manage      the 

cumbers  cf  available  radios  onboard  a  ship  for  comparison 
with    the  installed   capability.  Second,      this    module   will 

display  the  participants  of  a  specified  communications 
circuit      en     the      graphics      menitor.  The      query/response 

sequencing  is  accomplished  through  the  use  of  menus  from 
which  a  number  entry  is  required  to  specify  a  desired 
option.  Unlike   the      SENSOR    and      WEAPONS    modules,         which 

cannot  be  operated  if  a  graphics  capability  does  not  exist, 
the  radio  numbers  management  capabilities  of  this  subroutine 
can    be   exercised    without   any   graphics    capability. 

5.       SENSOR    Module 

fhis  module  is  totally  reliant  upon  computer 
graphics  for  its  operations.  The  call  from  the  MAIN  module 
to  this  irodule  is  made  through  a  graphics  control  subroutine 
discussed  later.  This  is  the  reason  that  th<=>  SENSOR  module 
cannot  be  operated  without  a  computer  graphics  capability, 
fcithin  this  module,  the  user  can  generate  displays  of  the 
coverage  areas  of  specified  force  sensors.  The  identifica- 
tion cf  the  specific  sensor  is  made  in  a  manner  similar  to 
that    used      in  the  STATUS      mcdule.  The   command      string   for 

this  icdule  is  allocated  34  characters  in  length,  and  is 
comprised  cf  two  components  which  are  seperated,  and 
converted   to  character   representation.        This   is 
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accorcp lished  through  the  use  of  the  ENCODE  Fortran  exten- 
sion. Once  the  segments  of  the  command  string  are  identi- 
fied, a  BLOCK  IF  ccnstruction  is  utilized  to  direct  the 
program  flew  through  the  various  options.  There  are 
rumercus  calls  to  EI-3000  unique  subroutines  within  this 
module;    however,    they  will    not   be   discussed. 

a.  PLOTP  and   FLOTC    Subroutines 

While  organic  tc  the  SENSOR  module,  these 
subroutines  are  principally  utilized  by  the  POSITION  capa- 
bility of  the  BUILD  nodule.  The  PLOTP/PLOTC  subroutines 
will  translate  the  user's  polar  or  cartesian  positions  for  a 
unit  into  useable  coordinates  for  the  graphics  displays. 
Ihe  PLOTP  subroutine  uses  a  trigonometric  calculation  to 
make  this  conversion,  whereas  the  PLOTC  subroutine  utilizes 
a  BLOCK  IF  constructicn  which  makes  a  comparison  to  the  "ZZ" 
unit's   "tase"   positicr. 

b.  AREA   Subroutine 

The  AREA  subroutine  is  the  principle  program 
driver  ficm  which  tie  coverage  areas  of  the  various  force 
sensors   and     weapons    are   generated.  This      subroutine   will 

cause  the  VIEWPORT  tc  ba  defined  for  the  coverage  display. 
Additionally,  it  will  convert  the  name  of  a  ship  into  an 
internal  form  useable  by  the  graphics  system,  through  the 
use    cf      the    NAMS_CONVIRT   subroutine.  AREA   will      call   the 

DISEAT  subroutine  in  the  STATUS  module  to  obtain  the  range 
for  the  specific  sensor  or  weapon  system  it  is  plotting. 
While  crganic  to  the  SENSOR  mcdule,  this  subroutine  is  also 
utilized   by   the    WEAPONS   module. 

c.  ASW_AREA    Subroutine 

This  sutroutine  is  a  derivative  of  the  ABEA 
subrcutine    discussed    above.         The   reason    for    the 
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dif f eiertiation  between  these  two  capabilities  is  that  the 
force  ASW  display  features  are  more  complex  than  thosa  used 
in   displaying   the      radar   coverages.  This   is      because   with 

the  ASW  display,  optional  convergence  zone  capabilities  must 
be  identified,  matched  to  the  sonars  capable,  which  are 
further  matched  to  those  shins  which  have  those  sonars. 
Similar  to  the  AREA  subroutine,  ASW_ARZA  will  establish  the 
graphics  VIEWPORT,  convert  the  name  of  the  ship  into  useable 
graphics  form,  and  access  the  range  of  the  specific  equip- 
ments   thicugh   the   DISEAT   subroutine. 

d.  Sensor    Display    —    Title   Generation 

The  generation  of  the  titles  for  ths  various 
display  options  in  the  SENSOR  module  is  discussed  collec- 
tively for  all  the  module  options.  The  following  subrou- 
tines are  used  to  place  the  display  title  on  the  graphics 
lonitcr:  air_search,  sureace_search,  fire_control,  and 
SUB_SCRfflCE.  The  displays  to  which  these  subroutines 
correspond  should  be  evident.  The  operations  of  each  of 
these  subroutines  is  identical.  Each  will  establish  a 
secondary  VIEWPORT  and  WIN  DO  at  the  bottom  cf  the  monitor, 
and  will  displa j  the  text  primitives  reflective  of  the 
information   shown  on   the   graphics   plot. 

e.  CZ_ZONE    Subroutine 

The  function  of  this  subroutine  is  to  ascertain 
first,  whether  convergence  zone  sonar  propagations  exist, 
and  second,  if  they  do,  does  the  unit  being  displayed  have  a 
sonar  capable  of  operating  in  this  mode.  The  determination 
cf  the  existence  of  the  propagation  mode  is  done  through  a 
YES/NC  query  which  establishes  the  value  of  a  logical  vari- 
able which  is  passed  to  the  subroutine.  Once  determined,  a 
COMPUTED  GOTO  construction,  through  the  comparison  with  the 
ceded    sonar     type  onboard  the      unit   concerned,         generates   a 
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logical  variable  "CCKVERG,"  which  keys  the  display  of  the 
second   coverage    zone   en   the    ASW   sonar  display. 

6  .       fcE  A  PONS    Module 

As  its  name  implies,  this  module  is  utilized  to 
display  the  coverage  areas  of  the  force  weapons  systems. 
Like  the  SENSOR  module,  WEAPONS  is  totally  reliant  on  a 
graphics  capability  and  is  invoked  from  the  MAIN  module 
through   a   graphics   control      sequence.  The   module   operates 

from  a  master  menu  where  the  user  selacts  a  specific  weapon 
capability    to      be   displayed.  The   langthy      command   strings 

utilized  in   earlier    ncdules    dc      not   apply   to    WEAPONS.  The 

module  functions  through  the  use  of  a  BLOCK  IF  cons-ruction 
discr imirat ing  between  the  various  weapons  capabilities. 
WEAPONS  uses  self-contained  program  code  for  the  generation 
cf   all  available   displays.  This   code   is    identical   to   that 

used  in  the  SENSOR  module,  but  additionally,  allows  for  the 
display  cf  multiple  capabilities  simultaneously,  for  example 
TOMAHAWK    and   HARPOON,    or   MISSILE    and    GUN. 

a.  WEA?CNS_LABEL  Subroutine 

As  the  naire  implies,  this  subroutine  is  designed 
to  generate  the  labels  for  the  coverage  displays  selected  in 
the    WEAPCNS      module.  A   BLOCK      IF    construction    is      used   to 

create  the  appropriate  label  based  on  the  capability  being 
displayed. 

b.  ASW_WEAPS  Subroutine 

This  subroutine  displays  the  coverages  for  the 
force    ASW      weapons    systems.  The    subroutine      will    assemble 

and  display  a  coverage  view  reflective  of  each  unit's  heli- 
copter, ASW-Rocket,  and  torpedo  capabilities.  Each  of 
these    capabilities    are   color   coded   in   the    view. 
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7-       I  AT  ABASE    Module 

This  module  will  display  to  the  terminal  screen,  tha 
names  and  hull  numbers  of  the  ships  in  tne  master  database, 
grouped    according  to      ship    type.  This    module      is   operated 

through  the  use  of  a  menu  from  which  an  identification 
number  ccrr esponding  to  the  desired  ship  type  is  selected. 
The  mcdule  then  uses  a  COMPUTED  GOTO  construction  to  effect 
the  computation  of  the  key  value  and  key  field  length  neces- 
sary for  accessing  the  appropriate  records  in  the  master 
database. 

8.      SAVE  Module 

The  purpose  of  this  module  is  to  store  the  developed 
battle  group  database  prior  to  a  session  termination,  should 
the    user   so    desire.  This    mcdule   will   extract   the    database 

values,  and  create  the  three  files  discussed  earlier, 
FOR007.IAT,    FOR008.DAT,      and    FOP009.DAT.  Once    these    files 

are  created,  the  module  will  issue  the  FORTRAN  STOP  command, 
thereby   terminating    the   session.  Designed    into    the    schema 

cf  the  DSS  is  a  program  initiated  automatic  save  of  the 
tattle  croup  database  after  initialization  in  the  BUILD 
nodule.  This      is    dene      only    to      provide    a      back-up   should 

power  be  interrupted  but  will  not  guarantee  permanent  reten- 
tion of  the  database  should  the  user  terminate  his/her 
session    with  a    STOP    command    from    the    MAIN    module. 

g  •      II§.J££  Subroutines 

a.      WAIT   Subroutine 

This  subroutine  is  incorporated  into  every 
module  to  allow  the  user  to  pause  and  take  some  time 
reviewing   the  displayed   information.  Its   construction   is 

simply  providing  instructions  to  "Press  return,"  and  a  READ 
statement    which    looks   for   an    A1    formatted    variable. 
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t.      MANUAL    Subroutine 

This      subroutine      is      lengthy.  It      has      beer. 

designed   tc   accomplish   two    major   functions.  First,    should 

a  ship  in  the  battle  group  net  reside  in  the  master  data- 
base, this  subroutine  allows  that  unit's  capability  record 
to  be  written  to  bcth  the  battle  group  database  and  the 
naster  database  (through  the  use  of  the  DATA_CHANGE  subrou- 
tine) .  The  construction  of  this  subroutine  is  oriented 
around  multiple  queries  and  capability  menus.  The  user 
need  only  select  the  appropriate  capability  from  the  menu  tc 
include  that  capability  on  the  ship  in  question.  The 
MANUAL  subroutine  is  also  used  by  the  STATUS  module  in 
changing  an  element  cf  a  unites  database  record.  By  desig- 
nation cf  the  desired  capability  to  be  changed,  the  appro- 
priate menu  from  this  module  is  displayed  for  capability 
selection. 

c.  CONTBOL    Subroutine 

The    CONTICL     subroutine   exists    as   the      front    and 
back    end      program   unit      for    all      graphics   displays.  This 

subroutine  makes  the  foundational  calls  to  the  required 
EI-3000    craphics  routines.  Additionally,      this    subroutine 

will  determine  the  number  of  the  desired  graphics  meniter  to 
te   used.        This    number  is   unique   to   the    WARLAB  at    NPS. 

d.  GRID   Subroutine 

This   subroutine    overlays      a    cartesian    coordinate 
grid    cr.      the  displayed      capability   coverage      display.  The 

grid  is  scaled  to  the  size  of  the  plot  in  use,  and  its 
origin  is  offset  coiriiensur ate  with  -he  cartesian  position 
cf    the    unit  at    "ZZ. " 
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€-      THREAT    Subroutine 

This  subroutine  crsaiss  a  threat  sector  en  tod 
of  a  displayed  capability  coverage.  The  parameters  for  thc 
generation  of  this  sector,  are  the  threat  bearing  and  sector 
width,  both  provided  by  the  user  through  a  query  dialogue 
with    the   system. 

f.  MOVE   Subroutine 

A  major  capability  of  this  DSS  is  to  allow  the 
user  to  experiment  with  the  coverage  display  created  by 
irovirg  a  unit  and  observing  the  resultant  effect  on  coverage 
that      moving  the     ship's   sensor/weapon      would   have.  This 

subroutine  parallels  the  main  graphics  modules  by  repeating 
their  displays  with  a  designated  new  position  for  a  unit 
identified      by    the      user.  MOVE      will   create      colcr-ccded 

companion  references  to  the  old  position  as  well  as  generate 
legends  for  evaluation  of  the  new  information  being 
displayed.  MOVE    is  only    called   from    the    SENSOR    or    WEAPONS 

modules. 

g.  COMBAT    Subroutine 

This  subroutine  is  used  to  discriminate  between 
surface  combatant  ship  types  and  those  non-combatant  ship 
types.  It  is    called   from      the    MANUAL    subroutine   to    elimi- 

nate the  query  for  a  database  item  not  available  to  the  ship 
type    whose    database    record    is    being   created. 

h.      LIST   Subroutine 

The  LISI  subroutine  simply  utilizes  the  link 
list  structure  of  tte  battle  group  database  to  display  the 
rames  of  the  units  in  the  battle  group.  This  subroutine  is 
called  whenever  identification  of  a  battle  group  unit  is 
reguirad,   to  assist    the   user   in   making  the    correct    response. 


50 


i.      LOCATE    Subroutine 

This  subroutine  is  utilized  whenever  a  ship  name 
from  the  battle  group  is  the  dasired  input  to  a  query. 
LOCATE  will,  as  its  name  implies,  locate  the  ship  within  the 
link  list  structure,  flag  it  "found,"  and  pass  the  sequence 
number      of   the      ship      back    to      the     calling   module.  This 

subroutine    is   used    throughout   the   program. 

j.      NAME_CONVERT   Subroutine 

NAHE_CONVERT  will  truncate  the  name  of  a  ship 
for    use      in  the      graphics   displays.  This    subroutine      was 

devised  to  eliminate  some  of  the  clutter  generated  by  the 
overlapping  of  the  ship*s  names  on  the  plots.  However,  its 
principle  function  is  to  convert  the  name  of  the  ship,  a 
character  variable,  into  an  internal  form  useable  by  the 
DI-30C0   text  primitives. 

k.      ORIENT    Subroutine 

This  subroutine  compares  the  coordinates  of  the 
ships  graphics  position  with  the  quadrant  in  which  it  is  in, 
and  establishes  the  appropriate  justification  values  for  the 
JJUST   call    in  the  DI-jO00  text   output    primitive.  It    basi- 

cally justifies  the  name  to  ensure  it  is  pointing  outward, 
away    from   the   center   cf   the    plot. 

1.      DATA_CHANGE    Subroutine 

DATA_CHAKGE  will  accomplish  one  of  two  things. 
first,  it  will  write  a  manually  developed  ship  database 
record      to    the      roaster   database.  If      the   record      already 

exists, this  subroutine  can  be  used  to  REWRITE  (discussed 
earlier)  the  record  should  the  user  desire  to  make  a  capa- 
bility  change  permanent. 
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Now  that  the  design  of  the  program  has  been 
discusssd,  the  next  chapter  of  this  thesis  will  address 
utilizing   the  DSS.  The   User's    Manual,    as   has    already   been 

mentioned,    can    be  used   as   a    reference,      or   as   an    instruction 
en   the   operations  of   the      DSS.  The   DSSdoes   explain   enough 

information   that   the      reading   cf   the    User's      Manual    prior   to 
conducting   a  session    is   not    necessary. 
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III.    DECISICH    SOPPCBT    SYSTEM    USER^S    HANDAL 

A.       INTRODUCTION 

Welcome  to  the  Eattle  Group  Asset  Management  Eecision 
Support  System.  New  that  you  are  ready  to  operate  the 
system,  the  topics  that  follow  will  elaborate  on  The  capa- 
bilities of  the  computer  program.  It  is  important  to 
recognize  at  the  outset  that  the  complexity  of  your  interac- 
tion with  the  system  is  NOT  dependant  on  your  having  a 
Computer  Science  degree.  You  cannot  "bomb"  the  program  or 
accidentally  damage  any  of  the  databases.  Every  request  for 
information  has  been  protected.  Should  you  inadvertantly 
enter  an  incorrect  character,  the  system  will  recognize  That 
fact  and  ask  you  to  reenter  an  acceptable  value.  This 
"error  checking"  alsc  applies  to  the  spelling  of  the  names 
cf  the  ships  you  will  be  usirg.  Your  bywords  should  be 
"relax,    I   can't    hurt    anything." 

With  an  eye  towards  flexibility,  the  program  can  be 
operated  either  from  the  keyboard  cf  a  computer  terminal  (in 
this  case  a  VT-100/1C2),  through  voice  recognition  equip- 
ment, or  through  both  simultaneously.  Throughout  this 
Oser*s  Manual,  both  the  keyboard  and  the  voice  entry 
response   options   will   be  shown    for   each    query. 

Ihe  database  for  this  DSS  in  oriented  to  the  Pacific 
Fleet.  The  130  ships  in  the  database  comprise  those  PACFLT 
units  whichcould  be  expected  to  be  assigned  to  a  tattle 
group.  While    the    service    force      units   are    included    in   the 

database,   there    are    no  amphibious   ships    included. 

If  ycu  were  to  group  the  program  capabilities  into  two 
general  categories,  you  would  differentiate  between  these 
portions   which      rely    en    graphics    software      (DI-3000)       unique 
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operations    and   those    that   don't.  In  general,    the    WEAPONS, 

SENSOB,      and  COMMS(fcr  the    display   Comm    Net   capability    only) 
modules    utilize    computer      graphics.  If    you  do      not   have   a 

graphics  capability  at  the  position  where  ycu  are  operating, 
then  ycu  cannot  attempt  to  utilize  these  sections  without 
causing  an  ERROR  to  cccur  in  the  computer  operating  system. 
If  this  applies  to  you,  simply  do  not  attempt  to  use  those 
secticns . 

This  User's  Manual  has  been  designed  tc  give  ycu  an 
exposure  tc  all  the  interactions  you  could  expect  to  have 
with  the  system.  In  each  example,  ycu  will  be  shown  sample 
entries  frcm  both  the  keyboard  (KB)  and  the  voice  reccgni- 
tion  (VH)  eguipment.  The  samples  will  be  prefaced  by  KB  or 
VR,  as  appropriate.  Throughout  the  manual,  when  entering  a 
command  frcm  the  keyboard,  you  will  be  reguired  to  depress 
the   CSBB3AGE  RETURN      key    (designated   as   <cr>)  .  Also,      all 

ccmmands   frcm      the    keyboard    MUST      be    in    upper      case.  This 

differs  scmewhat  fron  the  operations  using  the  voice  recog- 
nition equipment.  There  will  be  some  voice  ccmmands  which 
already  have  incorporated  into  their  output  strings  a 
CARRIAGE  BETURN.  There  will  be  others,  however,  which 
require  that  the  CARRIAGE  BETURN  command  be  input. 
Examples  for  the  commands  frcm  the  VR  equipment  will  be  very 
explicit,  and  will  show  the  command  "Carriage  Return",  if 
required.  You  can  refer  to  Appendix  A  for  a  detailed 
explanation  of  the  voice  commands  and  applicable  output 
strings. 

There  will  be  occasions  when  the  sampl3  command  is  shewn 
within   the   text    cf    a   corresponding      explanation.  In    these 

cases,      the   commands    will   be   shown    within    quotes.  If  they 

are  keyboard  ccmmands,  DO  NCT  enter  the  quotes  with  the 
cemmand,  simply  enter  the  portion  of  the  example  within  the 
quotes. 
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While  we  are  on  the  topic  of  the  CARRIAGE  RETURN  func- 
tion, the  program  will  occasionally  pause  to  allow  ycu  to 
examine   the      information   on      the    screen.  In  these      cases, 

there  will  appear  at  the  bottom  cf  the  screen  the  following 
statement. 

***   PRESS    CABRIAGE    CONTROL    TO    CONTINUE    *** 

lc   carry   out  this   command,     jou    would   enter   the   following: 

KB      —  <cr> 

VR      —      "Carriage    Return" 

Finally,  in  most  cases,  the  screen  display  for  the 
queries  we  will  be  discussing  will  be  shown  in  figures 
adjoining  the  explanation.  There  will  be  some  occasions 
where  th€  information  displayed  in  a  figure  will  not  te  in 
the  exact  format  which  ycu  would  sae  on  the  screen.  This  is 
due  to  the  fact  that  en  the  screen,  80  columns  of  informa- 
tion can  be  displayed,  whereas  in  the  figures,  only  54 
columns    cf    information   can    be      shewn.  The   contents   of   the 

information  in  the  figures  will  be  complete,  however  its 
format  will  be  different.  In  these  cases,  the  reference  to 
the  applicable  figure  will  have  "(adjusted)"  written  after 
the    figure    number.  An   example    of   this    would  be    when    there 

are  two  large  groups  of  information  displayed  side  by  side 
on   the   screen.  In    most  cases,    the    figure   representing   the 

information  would  shew  the  same  information  in  a  single 
columnar    fashion.  This      will   become    more   clear      to    ycu  as 

ycu  proceed  through  this  manual,  and  operate  the  system. 
The    next   step   is   to    c€t    going    with   the   system. 

B.       INITIATING    THE    PBCGRAH    IT    THE    TERMINAL    STATION 

Logging  on  to  a  computer  system  and  running  a  program 
are    unique    to  the   particular   system.        This    Decision   Suppcrt 
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Systeir  was  developed  on  a  VAX  11/780  computer  system  which 
had  a  EAMTEK  color  graphics  capability  associated  with  the 
computer  operating  system.  The  following  procedures  are 
unique   to   this   systen.  Ycu    opay   have   to   adapt    them   to   ycur 

cwn    system   as  appropriate.  If      you    are   also   utilizing   the 

CT-600  voice  recognition  equipment,  you  should  lead  the 
voice  tape  into  the  program  tape  reader  at  this  time. 
additionally,  connect  the  T-600/VT- 100/102  and  the  VAX 
11/780  together  using  the  interface  designed  for  this 
purpese    in    the    WARLAE.        Now   you   are   ready    to    go. 

If      USEENAME  is      cot   currently      being      displayed   on      the 
terminal    screen,    you    should    enter   the    following: 

KB      —  <cr> 

VR      —      "Carriage    Return" 

1  •      login/Pr  cgrair  Initiation   from    the   Keyboard 

Eow  that  USEFKAME  is  being  displayed,  and  ycu  are 
operating    from    the    keyboard,        enter   "DECISION  <cr>".  You 

will    new    see  PASSWORD  being      displayed.  (Obtain   the    pass- 

word   from   the   WARLAB    staff,    and    make   the   appropriate   entry.) 
This    display      will    end    with    the      symbol    $,      and    ycu      are   now 
ready   to   run     the   prcgram.         Enter    "RUN    DSS      <cr>",      and   you 
will    begin      to    see      the    displays      from   the      Decision   Support 
System. 

2-      Login/Prog  ran   Initiation   through   Voice  Equipment 

If  you  are  operating  with  the  voice  equipment,  enter 
"LOG  DECISION  ON."  Ycu  will  then  see  administrative  infor- 
mation frcm  the  operating  system  on  the  screen,  followed  by 
the    symbol    S.  Now  enter    "RUN    DSS   PROGRAM,"      and    you   will 

begin    to   see  the   displays   from   the   Decision   Support    System. 
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C-       PBOGFAM    DATABASE    IHITIAIIZ ATION 

As  was  discussed  in  Chapter  I  of  this  Decisicr.  Support 
Systeir,  you  have  the  capability  to  work  within  the  system 
and  tfcen  terminate  a  session  without  loosing  the  information 
you   have   developed    abcut  your      battle   group.  This    is   acne 

through   the   use      of    tte   SAVE   module.  When      you   commence   a 

run/session  of  the  svstem,  you  will  be  presented  with  one  of 
two    series    of      gueries   for    information.  The      one    which   is 

presented  will  depend  on  whether  you  have  stored  a  battle 
group    database    from      a   previous   session.  We      will   lock   at 

both  versions.  We  will  first  examine  the  situation  where 
there  is  a  saved  database  and  then  look  at  one  in  which 
there   is   ncne. 

1  •      Eattle    Group    Formed    During   Previous   Session 

If  this  is  net  your  first  session  with  the  battle 
group  database,  then  you  will  be  initially  shewn  the 
existing  composition  of  the  battle  group  in  the  database. 
Figure  3.1  shows  an  example  of  the  view  you  would  see  and 
reflects  a  five  (5)  ship  battle  group  consisting  of  USS 
NlfllTZ,  CSS  PAUL  F  FCSTEE,  USS  YORKTOWN,  USS  MERRILL,  and 
USS    GUIT2RBC  already      created.  You    will    be      gueried   as  to 

whether  or  not  you  desire  to  continue  with  this  battle 
group . 


a.      Desire   tc  Retain   the    Battle   Group 

If  you  desire  to  retain  the  existing  battle 
group  database,  then  you  would  respond  to  this  guery  as 
follows: 

KE      —  YES    <cr> 

VB      —      "Affirmative" 
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A    EATTLE    GROUP    DATAEASE     HAS    BEEN    SAVED    FROM    A    PREVIOUS 
SESSION.       BATTLE    GROUP    COMPOSITION    IS    AS    FOLLOWS: 

NIMITZ 

PAUL    F    FCSTER 

YORKTOWN 

MERRILL 

GUITARRO 

???       WOULD    YOU    LIKE    TO    CONTINUE    WITH    THIS    DATABASE    ? ?? 

(YES    CR    NO) 


Figure  3.1    Battle  Group  Already  Formed. 

h.   Does  Not  Desire  to  Retain  the  Battle  Group 

If  you  <3c  net  desire  to  retain  the  existing 
tattle  group  database,  then  you  would  respond  to  the  query 
as  follows: 

FB   —      NO  <cr> 

VR  —   "Negativa" 

The  battle  group   database  has  now  been  erased   and  ycu  will 
receive  the  following  confirmation  on  the  screen. 

SHE  DASAEASE   HAS  BEEN  DELETED  AND   A  NEW  BATTLE   GROUP  MUST 
NOW  EE  ECILS. 


c.   Error  in  Making  Response 

Figure  3.2  shows  the  display  you  will  receive  if 
you  inadvertantly  make  a  mistake  in  entering  the  YES/NO 
response.    Should  this  occur,  simply  reenter  the  response. 


58 


YCDE    EESPONSE    IS    NCT    REC CGNIZEABLE    AS    AN    ACCEPTABLE 
ANSWEB.       PLEASE    ENIER    YES    OR    NO. 


Figure  3. 2        Error  in   Making   IES/NO    Response. 

2  •      Program    Operation  B ase d   on   Response 

Now  that  you  have  made  the  decision  as  to  whether  or 
net  ycu  desire  to  retain  a  previously  formed  battle  group, 
the  system  will  do  one  of  two  things  based  on  ycur  decision. 
If  your  response  was  "Yes, "  the  battle  group  database  will 
fce  leaded  into  the  operating  section  of  the  system,  This 
will  be  transparent  tc  you  with  the  exception  of  a  possible 
one      second     delay      in   refreshing      the      screen.  If      your 

response  was  "No,"  then  as  was  confirmsd  to  you,  the  battle 
group  database  has  been  deleted.  In  either  case,  the  next 
view  that  ycu  would  see  is  the  same  as  if  you  were  starting 
the  system  without  any  previous  information  being  saved. 
That    will   be  the  topic   of  our    next   section. 

3-      Review   of   Main   Menu    Options 

If  you  are  initially  forming  a  battle  group,  or  you 
have  already  decided  en  the  disposition  of  the  saved  battle 
group  catarase,  then  the  next  query  you  will  receive  will  be 
to  deteririne  if  you  desire  to  review  the  Main  Menu  options, 
as    shewn    in    Figure    3.3. 

If  you  desire  to  review  the  options,  enter  the 
following: 

KE      —  YES    <cr> 

VR      —      "Affirmative" 
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???  SCGLD  YOU  LIKE  TO  REVIEW  THE  MAIN  MENU  OPTIONS  ??? 
(YES/NO)  I 

I 


Figure  3.3        Review  of   Main   Menu   Options  Query. 


If      ycu      DO   NOT      desire  to  review      the    options 
following: 

KB  —  NO   <cr> 

VR  —  "Negative" 


enter     the 


a.      Error   in    Making    YES/NO    Response 

If  ycu  inadvertantly  make  a  mistake  in  entering 
the  YES/NO  response,  you  will  see  the  view  as  shown  in 
Figure    3.2,    on    the    screen.  If   this   occurs,    simply    reenter 

your    response. 

4  .      Displa  v    of    Main    Men u    Options 

If  your  response  was  to  display  the  Main  Menu 
Cpticns,  then  ycu  wculd  have  the  display  as  shown  in  Figure 
3.4  (adjusted)  and  Figure  3.5  (adjusted)  displayed  on  the 
screen.  They  are  presented  in  two  segments  as  the  amount  of 
inf ornatici  shown  exceeds  the  capability  imposed  by  the  size 
cf   the    terminal    screen. 


fihen  you   are  ready    to   continue,      enter  the   fcllcwing 

to    see   the   remainder  cf   thee    menu. 

KB  —  <cr> 

VR  —      "Carriage   Return" 
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***    PRESS    CARRIAGE    RETURN    TO    CONTINUE    *** 


Figure    3.4        Bain   Menu  Options. 


when  you  are  ready  to  continue,  enter  the  CARRIAGE 
RETURN   command    as  described    above. 

5-      Selection   of   Main  Menu  Options 

it  this  point,  you  will  be  queried  as  tc  which 
cpticr  ycu  desire  to  utilize.  This  query  is  shown  in  Figure 
3.  6. 

There  is  one  caution  which  you  should  be  aware  of 
before   ycu    make    your   selection.  If    the    battle    group    data- 

base eiists  and  you  have  retained  it,  then  you  are  free  to 
select  any  of  the  Main  Menu  options  shown  in  Figure  3.6. 
However,  if  this  is  the  first  session  you  are  having  with 
the   system,      and/or    the   battle   group   has   net,      as    yet,      been 
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Figure  3. 5   Main  Menu  Options  (conti)  . 


?  SELECT  ONE  OF  TEE  FOLLOWING: 

BUILD     STATUS     COMMS     WEAPONS 
SAVE      SENSOR     STOP      DATABASE 


IF    YOU 
"MENU" 


DESIRE    TO    REVIEW    THE    MAIN    MENU    OPTIONS    ENTER 


figure    3,6         Selection   of   Main   Menu  Option. 

formed,  jcur  selections  are  restricted  to  either  the 
DATABASE  or  BUILD  options.  The  reason  for  this  is  that  all 
ether  system  modules  require  seme  or  all  of  the  information 
contained  in  the  database,  which  either  must  exist  or 
initially   te  establisted   in    the      BUILD    module.  Should    you 
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accidentally  attempt  to  enter  ether  than  the  DATAEASE  or 
BUILC  ncdules  in  this  case,  you  will  receive  the  following 
warning    and  will   be    placed    in   the  BUILD    module. 

THERE  ARE  NO  UNITS  IK  THE  BATTLE  GROUP  DATAEASE  AND  YOU  MOST 
FIRST    EUILE    THE    BATTLE    GROUP.  PLEASE    ANSWER   THE    FOLLOWING 

QUESTIONS. 

For  a  more  detailed  explanation  of  the  operations  of 
the  various  modules  in  the  system,  refer  to  the  appropriate 
section    en      the    operations    of      that    module.  For    example, 

information  on  the  DATABASE  module  would  be  found  in  the 
section   entitled      DATABASE    module  Operations.  If      ycu    are 

initially  forming  the  tattle  group,  the  the  following  short 
description  of  the  functions  of  the  BUILD  module  will  te  of 
some    value. 

a.      BUILD      Module      Functions        During      Battle      Group 
Initialization 

When   you   are   forming   the   battle   group,    the    EUILD 
module    will   orchestrate   the    collection   of    data  as   follows: 

•  Number   of   units    in    your    battle   group 

•  Names   of  the    units   in    your    battle   group 

•  Name  of  the  battle  group  unit  to  be  designated  as  "ZZM 
(for  the  purposes  of  this  Decision  Support  System,  a 
tattle    group   unit   MUST    be   at    "ZZ") 

•  Type  of  coordinate  system  used  for  stationing  assign- 
ments    (POLAR    or    CARTESIAN) 

•  Positions   of  all    units    in   the   battle   group 

•  Composite    Warfare  Commander    (CWC)    Organization 

•  Helicopter    embarcation    status   for    HELO   capable    units 
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Once  you  have  identified  the  names  of  the  units 
in  your  tattle  group,  information  concerning  tha  onboard 
sensors,  weapons  systems,  and  administrative  information 
(e.g.  Group  Commander),  unique  to  each  unit,  is  automati- 
cally obtained  from  a  master  database.  This  database 
contains  in  excess  of  13  0  ships  from  which  to  choose. 
Should  a  unit  in  your  battle  group  net  be  in  this  master 
database,  you  will  be  asked  to  provide  the  necessary  infor- 
mation manually  through  the  use  of  capability  menus 
(discussed  in  BUILD  Module  Cperations)  provided  on  the 
terminal  screen.  Once  this  na-nual  operation  is  complete, 
the  unit  will  be  permanently  placed  in  the  master  database 
so  that  in  the  future,  manual  information  insertion  will  not 
be  necessary   for  that   unit. 

6 •      Mistake    in    Requesting    a    Main    Man  u   Option 

To  protect  ycu  should  a  mistake  be  made,  there  are 
parts  of  this  system  which  will  check  your  entries  and  if 
they  are  incorrect,  advise  you  of  such  and  allow  you  to  make 
a  correct   entry.  An   example   is   contained    in   the    following 

section. 

a.      Mispelling   of  a    Main    Menu   Option 

Should  ycu  accidentally  mispell  a  request  for  a 
Main  Menu  Option,  you  will  receive  a  warning  as  shewn  in 
Figure    3.7. 

To  correct  this  mistake,  simply  reenter  the 
desired    option.         Some   examples   ara    shown   below. 

KB      —      3UILD    <cr>        or         WEAtONS    <cr>         or        SENSOR    <cr> 
VR     —      "Builc    Module"      or      "Weapons   Module" 
or      "Sensor   Module" 
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YOUR    SELECTION,     AS    ENTERED,    DOES    NOT    CORRESPOND    TC    THE 
CHOICES     AVAILABLE    IN    THE    MAIN    MENU.       PLEASE    ENTER    ONE 
OF    THE    FOLLOWING: 


BUILD 

STATUS 

COMMS 

WEAPONS 

SAVE 

SESSCR 

STCP 

DATABASE 

MENU 

Figure  3.7        Bispelling  of  a    Main   Menu  Option. 

D.       Mllfl    MODULE    OPERATIONS 

The  Main  module,  as  an  entity,  may  be  transparent  to 
you.  It    has    been    designed      as    a   controller   that   organizes 

the  flow  cf  your  commands/desires  between  the  other  mcdulss. 
Its  principle  function  is  tc  provide  you  a  focal  point  from 
which    ycu    can    easily    neve    tc      the    other    modules.  Ycu   have 

already  seen  an  example  of  this  as  you  initialized  ycur 
battle  group  database  using  the  DATABASE  and/or  EUILD 
modules. 

As  ycu  move  through  the  modules,  when  you  elect  to 
finish  with  that  particular  module,  you  will  always  be 
returned  tc  the  Main  module.  This  is  signified  by  the  guery 
shown    in    Figure    3.3.  The    descriptions   of   each    module,      as 

shown  in  Figure  3.4  and  Figure  3.5,  are  self  explanatory. 
The  remainder  of  this  User's  Manual  is  organized  into 
sections  which  address  the  operations  cf  each  module.  In 
every  case,  you  will  te  walked  through  a  session  which  exer- 
cises the  capabilities  of  that  module,  as  well  as  be  shewn 
seme  cf  the  possible  pitfalls  or  problems  you  may  encounter. 
There  are  two  modules  that  reguire  some  emphasis  at  this 
point,  as  they  will  terminate  a  session  in  distinctly 
different      fashions.  These      are      the      STOP    and      the      SAVE 

modules.        They    will    te   discussed   next. 
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E.       "STOP"    MODULE    AND    "SAVE"    MODULE   OPERATIONS 

These  two  modules  are  discussed  together,  as  they  both 
result  in  the  termination  of  a  session  in  the  Decision 
Support    System.  The   SAVE    module,    however,    will    first    file 

all  the  tattle  croup  information  that  ycu  have  developed 
before    termination      occurs.  This      contrasts  to      the    func- 

tioning of  the  STOP  module  which  terminates  a  session 
without  filing  anj  of  the  developed  information. 
Terminating  a  session  with  the  STOP  module  will  require  you 
to  fcim  a  new  battle  group  at  the  beginning  of  your  next 
system    session.  Let's  briefly   expand   on   the  operations  of 

these    two    modules. 

1  •      ~K1I  Module    Operations 

The  SAVE  module  has  been  designed  to  store  the  data- 
base for  your  battle  croup  when  you  desire  to  terminate  your 
session.  It  is  invoked  from  the  query  shown  in  Figure  3.6, 
as    fellows: 

KE      —  SAVE   <cr> 

VB      —      "Save    Module" 

When  you  invoke  this  capability  of  the  DSS,  the  ship 
names,  capabilities,  positions,  administrative  data,  etc., 
which  ycu  have  developed  for  your  battle  group,  as  well  as 
the  CWC  Organization,  will  all  be  stored  for  future  use. 
Having  terminated  a  session  with  this  module,  when  ycu  rein- 
itiate a  DSS  session,  you  will  be  initially  be  presented 
with    the   information    shown    in    Figure    3.1. 

Session  termination  on  the  VAX  11/780  will  be  marked 
by  the  statement  FCETRAN  STOP  followed  by  the  symbol  $ 
appearing   on  the   screen.  When   this    occurs,    you    can   termi- 

nate   your    ESS   session      with    the    following    command. 
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FE      —         LCGO      <cr> 
VE     —      "Terminate" 

You  aie  row  finished,  and  can  turn  the  terminal  and  graphics 
(if    applicable)    off. 

2 .      STOF  Modul e   Operations 

The  functioning  of  the  STOP  module  is  straightfo- 
ward.  It  will  terminate  your  session  without  saving/ 
storing  any  of  the  information  which  you  have  developed.  It 
is   invoked    from    the    guery  shown   in    Figure    3.6,   as    follows: 

KE      —  STOP    <cr> 

VS      —       "Step    Module" 

If  you  have  no  future  reguirement  for  the  data  with 
which  you  have  teen  working,  then  this  is  the  capability 
that    ycu      should   use   to      terminate   your    DSS      session.  Any 

information  previously  stored  will  be  deleted  when  the  STOP 
rcodule    is   irvoked. 

The  pragmatics  of  a  session  termination  when  using 
the  STOF  module  on  the  VAX  11/780  are  identical  to  those 
described   in  the   section  on    the   SAVE   module   Operations. 

3  •      Frogram    Initiated  SAVE    Function 

Ihere  is  nothing  more  frustrating  to  the  experienced 
computer  user,  or  intimidating  to  the  inexperienced  user 
than  tc  have  the  program  "bomb,"  for  no  axplainable  reason. 
The  reasens  for  this  are,  of  course,  more  often  than  not, 
explainable.  However,      that    doesn't   restore  the    sometimes 

hours  cf  work  which  may  have  lead  up  to  the  incident.  That 
may    be   hcurs  of    work    which    were   lost. 

In  an  effort  to  alleviate  such  anxiety,  and  protect 
against  a  less  of  information,  the  Decision  Support  System 
has    been      designed    tc   perform      a    one-time    automatic      SAVE   of 
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the  information  which  you  have  entered.  This  will  cccur  at 
the  completion  cf  ycur  first  establishment  of  the  battle 
group   database    in   the   BUILD      module.  You   are   not   required 

to  perform  any  keystroke  cr  voice  command  to  effect  this 
SAVE.  In  fact,  with  the  exception  of  a  possible  1-2  second 
delay  in  refreshing  the  screen,  it  will  be  transparent  to 
you.  This  capability   is    identical   to   that    which   ycu    would 

use  by  invoking  the  SAVE  module,  with  the  exception  that  the 
session   will  NOT    be   terminated.  In   this    manner,      should  a 

power  failure  or  fluctuation  cause  the  program  to  "tcmfc," 
you  will  net  loose  tie  work  ycu  have  done.  When  you  reini- 
tiate the  program,  the  information  will  appear  as  shown  in 
Figure  3.1,  just  as  if  YOU  had  saved  it.  Invoking  the  STOP 
Module  will  erase  this  information  before  terminating  ycur 
ESS    session. 

P.       E11AEASE   MODULE    OPERATIONS 

There      could   be      two   situations      in    which      ycu    may      find 
yourself      when    using      this    decision      support    system.  The 

first,  and  most  predominant,  instance  will  be  that  you  have 
a  battle  group  formed  and  you  enter  the  names  of  the  units 
in   that    tattle    group    into  the   system.  Transparent    to    you, 

the  prcgram  will  take  those  names  and  extract  from  a  master 
database,  the  capabilities,  administrative  data,  etc., 
attributable  to    those   particular      units.  As  was    mentioned 

earlier,  there  are  some  130  ships  in  the  master  datatase. 
So,  ycu  can  see  that  all  ships  in  the  Navy  are  not  there. 
Inserticn  cf  the  name  of  a  unit  which  is  net  in  the  database 
would  require  you  to  enter  its  database  of  information  manu- 
ally. If  you  would  like  to  confirm  that  one  of  your  battle 
groups  units  is  in  the  master  database  prior  to  inserting 
its  name  in  the  BUILE  module,  you  could  invoke  the  DATABASE 
module  and  sccess  the  particular  ship  type  of  the  unit  for 
which    ycu   are  looking. 
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The  second  situation  ycu  iray  find  yourself  in  is  that 
you  are  experimenting  with  theoretical  battle  group  composi- 
tions, end  would  like  to  select  from  the  list  of  available 
units  the  ships  for  your  battle  group.  Again,  invoking  the 
EATAEJSE  module  will  allow  ycu  to  view  all  of  the  units  in 
the  master  database,  in  groupings  of  ship  type,  as  you 
desire. 

1  -   Invoking  the  EAT ABASE  Wodule 

Khen  presentee  with  the  query  shown  in  Figure  3.6, 
the  EATAEASE  module  can  be  invoked  as  follows: 

KB   —       DATABASE  <cr> 
VR   —   "Database  Module" 

This  entry  will  move  you  from  the  Main  module  into 
the  EATAEASE  module  aid  you  will  be  presented  with  the  query 
shown  in  Figure  3.8  (adjusted). 


2-   Selecting  a  ShiD  Tj££e  Option 

Figure  3.8  provides  the  menu  for  selection  of  the 
available  ship  types  in  the  master  database.  To  display 
the  names  and  hull  nuabers  of  the  units  in  a  particular  ship 
type  grouping,  simply  enter  the  number  corresponding  to  the 
ship  type  ycu  desire.  An  example  of  this  response  is  shewn 
below . 


KB   —  1  <cr>  or 

1 3  <cr> 

VR      —    "One"      "Carriage    Return"        or         "One"    "Three" 

"Carriage   Return" 
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************************  ****************************** 

*  3ATTIE  GROUP  ASSET  MANAGEMENT  * 

*  DECISION  SUPPORT  SYSTEM  * 
$                                                       $ 

*  *  DATABASE  MODULE  *  * 

*  * 
************************  ****************************** 

IBIS  KCEC1E  ALLOWS  YCU  TC  DISPLAY  THE  UNITS  IN  THE 
MASTER  DATABASE  AS  CATEGORIZED  BELOW.   SELECT  THE  NUM- 
BER CORRESPONDING  TO  THE  SHIP  TYPE  YOU  DESIRE. 

1  -  SUBMARINES     (SSN1 

2  -  AIRCRAET    CARRIERS     (CV/CVN) 

3  -  GUIDED    MISSILE    CBUISERS     (CG/CGN) 
U   -  DESTROYERS     (CD) 

5  -    GUIDED    MISSILE    DESTROYERS     (CEG) 

6  -  FRIGATES  (FF) 

7  -  GUIDED  MISSILE  FEIGATES  (FFG) 

8  -  BATTLESHIPS  (BB) 

9  -  REPLENISHMENT  OILERS  (AOR) 

10  -  FAST  COMBAT  SUPPORT  SHIPS  (AOE) 

11  -  COMBAT  STORES  SHIPS  (AFS) 

12  -  AMMUNITION  SHIPS  (AE) 

13  -  OILERS  (AO) 


Figure  3-8    DATABASE  Module  Selections. 

In  this  example,   the  ship  type  SUBMARINES  cr  OILERS 

would  be   selected.    Figure  3.9  is   an  example  of  what  you 

would  see  having  selected  the  ship  type  SUBMARINES  (SSN). 


*  SUBMARINES  * 

PEBMIT  SSN594  GUITARRO  SSN665 
LCS  ANGELES  SSS688  INDIANAPOLIS  SSN697 
LA  JCLLA      SSN701 

***  PRESS  RETUBN  TC  CONTINUE  *** 


Figure  3.9    SUBMARINES  in  the  Master  Database 
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If  your  selection  had  been  in  the  latter  example 
above,  ycu  would  be  selecting  the  OILER  (AO)  ship  type,  and 
Figure   3.10    shows   the   view    you   would   get   on  the   screen. 


*  OILERS  * 

CIMARRON     AC177  WILLAMETTE    AO180 

FIATTE       AC186 


***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.10   OILERS  in  the  Master  Database. 


Rhen  you  are  through  examining  the  ships  in  the  ship 
type  grouping  you  have  selected,  enter  the  following 
commands: 

KB   —  <cr> 

7R      —      "Carriage    Return" 

To  allow  you  the  opportunity  to  view  another  ship 
type t    ycu    will    receive   the    following    query. 

???    WOULD    YOU    LIKE    TO     SEE    ANOTHER    SHIP    TYPE    ??? 

(YES/NO) 

Your  response  to  this  query  would  be  the  following, 
as    applicable 

KB      —  YES    <cr>  or  NO   <cr> 

VR     --      "Affirmative"  or  "Negative" 

If  your  response  is  net  to  see  another  ship  type, 
then    ycu      will    be      returned    to      the    Main      module.  If      you 
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desire  tc  see  another  ship  type,   you  will  be  presented  with 
the  EATAEASE  module  irenu  (Figure  3.8). 

Should  you  inadvertantly  make  a  mistake  entering 
your  YES/NO  response,  ycu  will  be  presented  with  the 
following. 

PLEASE  ENTER  YES  OR  NO 

At  that  point,  simply  reenter  your  YES/NO  response. 

a.   Error  in  Selecting  Ship  Type  From  Menu 

Should  ycu  accidentally  make  an  incorrect  entry 
while  making  your  ship  type  selection,  you  will  be  presented 
with  the  following  on  the  screen. 

YOUR  SELECTION    DOES  NOT   CORRESPOND  TO   THE  MENU   OPTIONS. 
YOU  WILL  HAVE  TO  REENTER. 

***  PRESS  RETURN  TO  CONTINUE  *** 

To  continue,  make  the  CARRIAGE  RETURN  command  as 
described  above,  and  you  will  be  returned  to  the  DATABASE 
module  menu. 

G.   BDILE  MODULE  OPERATIONS 

While  the  MAIN  mcdule  is  the  hub  of  activity  between  the 
modules  cf  ths  system,  the  BUIID  module  develops  the  founda- 
tion upon  which  the  entire  system  will  operate.  Within  the 
BUILD  module,  the  composition  cf  the  battle  group  in  deter- 
mined, unit  positions  assigned,  and  the  Composite  Warfare 
Commander  (CWC)  organization  managed.  There  are  twc 
dif f erentiable  segments  to  the  BUILD  mcdule.  They  are 
oriented  around  whether  a  battle  group  database  (previously 
specified  by  the  user)  already  exists. 

when  there  is  nc  battle  group  formed,  you  will  first 
work  within  this  module  to  identify   the  names  of  the  battle 
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group  units,  their  positions  and  helicopter  embarcation 
status.  Additionally,   along   the   way,      you   will    identify  a 

unit  which  will  function  as  "ZZ"  (Remember  that  this  system 
requires  a  battle  group  unit  be  at  "ZZ."),  specify  a  coordi- 
nate system  to  be  utilized,  and  identify  the  organizations 
which      will      function      as        warfare      commanders.  As      was 

nenticned  earlier,  when  you  specify  a  unit's  name,  its  data- 
base is  automatically  obtained  unless  the  ship  dees  not 
reside  in  the  master  database,  in  which  case  you  would  manu- 
ally   enter   that    data. 

Cnce  the  battle  group  has  been  formed,  you  would  use  the 
EUILE  module  to  INSEET  or  DELETE  a  unit,  or  to  REBUILD  the 
entire  battle  group  database.  when  you  exercise  the  INSERT 
capability,  you  would  go  through  the  same  sequence  of 
gueries  regarding  the  unit  to  be  inserted  as  you  did  when 
initially   forming  the  battle   group.  When   you    exercise   the 

EELETE  capability,  as  the  came  implies,  you  wculd  be 
removing  the  information  for  the  specified  unit  from  the 
tattle   group  database.  The      REBUILD   capability   allows   you 

to  construct  a    completely  new   battle   group    database. 

In  the  following  sections,  we  will  move  through  the 
EUILE  mccule  and  demonstrate  the  interactions  you  can  antic- 
ipate having.  The  EUILD  module  is  invoiced  from  the  query 
shown    in    Figure    3.6,    as    follows. 

KB      —  EUILD      <cr> 

VR      --         "Build   Module" 

We    will   row   go   through   the    operations   of   this   module. 

1  •      Initially   Forming  a    Battle   Group 

For  the  purposes  of  our  example,  we  will  operate 
with  a  three  (3)  ship  battle  group  consisting  of  USS  CARL 
VINSON        (C7N-70)  ,       USS       PAUL       F       FOSTER     (DD-964)   ,  and       USS 

CALIICENIA    (CGN-36)  (a  unit    net      in    the      master    database). 
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The  first  view  which  you  will  be  shown  is  an  explanation  of 
the  functions  of  the  module,  and  is  shown  in  Figure  3.11 
(adjusted).  This      view  reiterates      much    of      what    we      have 

already    discussed   abcut   the    BUILD   module. 


BATTLE    GROUP    ASSET    MANAGEMENT 
DECISION    SUPPORT    SYSTEM 

BUILD    MODULE 

THIS    MODULE    WILL    SLLCW    YOU    TO    BUILD    A    DATABASE    OF    THE 
CAPABILITIES    OF    THE    UNITS    IN    YOUR    3ATTLE    GROUP.       THESE 
CAPABILITIES    WILL    INCLUDE    ALL    SENSOR    AND    WEAPONS    SYS- 
TEMS   CNBCARD,    AS     WELL    AS     NUMBERS    OF    UHF/HF    RADIOS    ON- 
ECARC.       THIS     DATA    HAS    BEEN    COMPILED    FOR    ALL    PACIFIC 
FLEET    UNITS.        YOU    WILL    BE    ASKED    TO    PROVIDE    THE    NAME    OF 
EACH    UNIT,    AND    THE    COMPUTER    WILL    LOCATE    THE    REQUIRED 
DATA    FOR    THAT    UNIT    AUTOMATICALLY.       SHOULD    A   UNIT    NOT 
BE    IN    THIS    MASTER    DATABASE,    YOU    WILL    BE    SO    INFORMED 
AND    THEN    YOU     WILL    EE    ASKED    TC    PROVIDE    THE    NECESSARY 
INFORMATION    IN    A     "PROMPT/ANSWER"    FORMAT.        YOU    WILL    NCW 
BE    ASKED    FOR    THE     SOMBER    CF    UNITS    IN    YOUR    BATTLE    GROUP, 
ANC    TEEN    THE    NAME    CF    EACH    UNIT.       PLEASE    ANSWER    THE 
QUESTIONS   AS    THEY    APPEAR. 

***    PRESS    RETURN    TC    CONTINUE    *** 


Figure   3.11        BUILD    Module    Discussion 


When      you      ere      ready     to  continue,         you      would      enter      the 
following: 

KB    —  <cr> 

VR    —        "Carriage   Return" 

The    next   guery      you    will   receive    is    for   the      number   of    ships 
in   your    tattle    group. 
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a.      Establishing   the    Number   of   Ships    in   Battle    Group 

This   will  be  the   cnly   time   you    will   be   asked   for 
the    total      number  of   ships    in      your   battle   group.  As   you 

operate  the  system,  once  this  value  has  been  initially 
entered,  it  will  be  automatically  kept  current  by  the 
system.  the   query      for  the   cumber   of    ships     in    the   battle 

group   is   shewn    in  Figure   3.  12    (adjusted)  . 


???    HCW    MANY    SURFACE    COMEATANTS,     CARRIERS),     SUBMAR- 
INES)    ARE    IN    YOUR    BATTLE    GROUP    ??? 

(ENTER    UF   TO    A    MAXIMUM   OF    25    SHIPS) 


Figure   3.  12        Query  —   Nu«ber  of   Ships   in   Battle   Group. 


As  the  query  shows,  the  range  for  the  required  input  is  1  - 
25  ships.  Since  cur  sample  battle  group  has  three  (3) 
ships,    we    wculd    enter  the   following. 

KB   --  3         <cr> 

VR  --  "Three"   "Carriage  Return" 

If  you  had  ten  (10)  ships  in  your  battle  group,   ycur   entry 
would  leck  like  this. 

KE  —  10   <cr> 

VR  --   "One"   "Zero"   "Carriage  Return" 

If  you  inadvertantly  make  a  mistake  in  making  this  entry, 
you  wculd  see  the  fcliowing  on  the  screen. 

THERE  HAS  EEEN  AN  ERROR  IN  INPUTTING  THE  NUM3ER  ON  UNITS  IN 
YOUR  EATTLE  GROUP.   YCU  WILL  HAVE  TO  REENTER  THE  NUMEER. 


75 


***    PFESS    RETURN    TO    CONTINUE    *** 

When  ycu  are  ready  tc  continue,  and  reenter  your  number  of 
ships,  enter  "RETURN, "as  described  above,  and  you  will  again 
be   given   the  query   shewn   in    Figure   3. 12. 

After  you  have  successfully  entered  the  number 
cf  ships  in  your  battle  group,  you  will  be  given  a  confirma- 
tion cf  your  entry,  as  shown  in  Figure  3.13.  The  statement 
would  shew  the  number  of  ships  ycu  entered,  and  ask  ycu  to 
confirm    that  the   number   is      correct.  In   our   example,      the 

number   of   ships    entered    was    three    (3) . 


THERE    IS/ARE       3    UNIT  (S)     IN    YOUR    EATTLE    GROUP. 
???     IS    THIS    CORRECT     (YES/NO)     ??? 


Figure  3. 13        Eattle    Group   Size  Confirmation. 


You  should  acknowledge  the  confirmation  with  the  fcllcwing 
response,    as  appropriate. 

KB      --  YES      <cr>  or  NO      <cr> 

VE      —  "Affirmative"  or  "Negative" 

Should  ycu  lake  an  error  entering  your  YES/NO  response,  you 
will    see   the  following   on  the    screen. 

PLEASE    ENTER    YES    OR    NO 

Simply  reenter  your  YES/NO  response  as  shown  above.  Should 
the  number  shown  in  the  confirmation  statement  be  incorrect, 
you  will  again  be  given  the  query  shown  in  Figure  3.12,  and 
the    sequence  of    events  described   above   will   b?  repeated. 
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t.   Ship  Name  Entry 

Once  you  have  identified  the  number  of  ships  in 
your  tattle  group,  the  next  step  will  be  to  enter  their 
names.  Following  your  confirmation  that  the  number  of 
ships  in  the  battle  group  is  correct,  the  explanation  shown 
in  Figure  3.14  (adjusted)  will  be  displayed. 


YOD  W 

IN  YO 

PEAR 

REFER 

TINGS 

FCF  A 

LIBIT 

ODS. 

TEF  N 

THE  D 

QUIRE 


ILL  NOW 

OR  EATTL 
AFTER  WH 
TO  YOUR 
FCR  THE 
VAILA3LE 
ED  TO  19 

SPACES 
AME  OF  T 
SER'S  MA 
E,  AND  V 


BE  ASFED  TO 

E  GRCDP.   A 

ICH  YCO  SHO 

USER'S  MAN 

FORMATS  OF 

SHIPS.   FO 

CHABACTERS 

BETWEEN  WOR 

HE  BATTLE  G 

NUAL,  THEN 

OICE  INPUT 


ENTER  THE  NAMES  OF  THE  UNITS 

PROMPT  "SHIP  NAME"  WILL  AP- 
ULD  ENTER  THE  NAME  OF  A  UNIT. 
UAL  UNDER  THE  "SHIP  NAME"  LIS- 

THE  KEYBOARD  OR  VOICE  ENTRIES 
R  KEYBOARD  ENTRIES,  NAMES  ARE 

WITHOUT  ANY  COMMAS  OR  SERI- 
ES COUNT  AS  CHARACTERS.   IF 
ROUP  UNIT  DOES  NOT  APPEAR  IN 
KEYECARD  ENTRY  WILL  BE  RE- 
WILL  NOT  WORK. 


***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3. 1<»   Ship  Naie  Entry  Explanation. 


When  ycu  are  ready  to  continue  and  enter  the  names  of  the 
ships  in  ycur  battle  group,  enter  "RETURN,"  as  described 
earlier,  and  you  will  receive  a  "SHIP  NAME  ?"  prompt. 

You  will  receive  this  prompt  a  number  of  times 
which  corresponds  to  the  number  of  ships  ycu  indicated  were 
in  ycur  battle  group.  You  should  note  that  if  you  are 
entering  the  information  from  the  keyboard,  you  are  limited 
to  nineteen  (19)  characters  for  a  ship's  name,  including 
spaces.  The  length  cf  the  names  of  the  ships  ycu  can  enter 
hy  voice  have  already  been  matched  to  this  requirement. 
Also  note  that  if  the  name  cf  a  ship  in  your  battle  group  is 
not  in   the  master   database  (as   you  could   confirm  in   the 
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DATABASE  module  discussed  earlier) ,  voice  entry  is  rot 
possible.  In  this  situation,  the  name  of  the  ship  would 
have  tc  te  entered  ficm  the  keyboard.  If  you  did  ncx  check 
the  names  cf  your  ships  in  the  DATABASE  module,  you  can 
confirm  the  names  in  Appendix  A.  If  the  name  of  a  ship  is 
shown  in  Appendix  A,  then  it  will  be  in  the  master  database. 
For  our  example  battle  group,  the  prompts  and 
applicable  responses  wculd  be  as  follows: 

SHIP  NAM1  ? 


KB       —  VINSON         <cr> 

VR       —         "VINSON" 

SHIP    NAMI    ? 

KB      --         FOSTER      <cr> 
VR       --         "ECSTER" 


or 
cr 


or 
cr 


CARL  VINSON    <cr> 
"CARL  VINSON" 


PAUL  F  FOSTER    <cr> 
"PAUL  F  FOSTER" 


SHIP  SAME  ? 

KB       —         CAIIFORNIA       <cr> 

VR        —         (not       possible  as      USS      CALIFORNIA    is      not    in      the 

nasxei   database) 

Should   ycu   make    an   error   in   entering    the    name   of 
a      ship,  you      will      see      the      following      on      the      screen. 

Usually,      the   only      cristake    you   can    make   is   to      enter    a   name 
longer   than   nineteen    (19)    characters. 


YOUR    INPCT    KAS     NOT    ACCEPTED    BY    THE    COMPUTER, 
10    REENIER    THE    SHIP'S    NAME. 


YOU  WILL  HAVE 


***  PRESS  RETURN  TO  CONTINUE  *** 

When  ycu  are  ready,  you  continue  as  described  earlier,  and 
the  "SHIP  NAME  ?"  prompt  will  appear.  Ycu  then  reenter 
the  name  of  the  ship. 
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Now  that  you  have  entered  the  names  of  the  ships 
in  ycur  tattle  group,  you  will  be  shown  the  composition  of 
the  cattle  group  that  you  have  entered  into  the  system. 
This  confirmation  ct€ck  is  very  important.  The  iraster 
database  is  keyed  to  the  names  of  the  ships,  and  if  the 
spelling  of  the  names  is  not  exact,  then  the  database  will 
treat  the  name  as  if  it  were  net  there,  and  the  user  will  be 
prompted  to  build  the  database  entries  for  that  unit  as 
explained  later.  The  system  has  been  programmed  to  recog- 
nize seme  short  form  names  of  ships  (e.g.  FOSTER  for  PAUL  F 
FOSTER,  o-z  VINSON  for  CARL  VINSON),  but  you  can  never  go 
wrong  by  using  the  full  ship  name.  Always  be  sure  that  you 
include  spaces  where  they  would  be  appropriate.  Figure 
3.15  (adjusted)  shows  the  composition  of  cur  example  battle 
group  foi  our  confir nation. 


HEBE  IS  A  LIST  OF  THE  SHIPS  YCU  HAVE  ENTERED  AS  YCUR 
EATTLE  GROUP.   PLEASE  CHECK  THE  LIST  FOR  ACCURACY  AND 
SPELLING. 


1  CARL  VINSON 
3  CALIEOBNIA 


2  PAUL  F  FOSTER 


PLEASE  ENSURE  THAT  THE  AEOVE  NAMES  ARE  CORRECTLY 
SPELLED.   IF  THEY  ARE,  PRESS  CARRIAGE  RETURN,  OTHER- 
WISE, ENIER  THE  NUMBER  OF  AN  INCORRECT  ENTRY  AND  EN- 
TER TEE  CORRECT  SPELLING  AFTER  THE  "SHIP  NAME  ?•■ 
PRCMPI. 


Figure  3.  15   Battle  Group  Naae  Listing, 


As  is  directed  in  Figure  3.15,  if  the  entries 
are  correct,  enter  "RETURN,"  (as  described  earlier)  ,  or  if 
not,   the  number  corresponding  to  the  incorrect   ship  name. 
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As  shewn  in  this  case,  the  list  is  correct,  and  we  should 
enter  BZTURN.  As  an  example,  however,  let  us  assume  that 
CARL  VINSON  was  accidentially  spelled  CARL  VINSAN.  Since 
this  is  incorrect,  ycu  would  enter  the  following. 

KB   —  1    <cr> 

VR     --        "Cne"      "Carriage   Return" 

You    would   new   see  the   view    shown    in   Figure    3.16. 


Jigure  3-  16       Correction  to   Ship  Name 


Notice      that     Figure    3. 16      shows      the      incorrect 
spelling   fcr     the   ship.  You   would     now    enter      the    correct 

spelling   fcr  the  VINSCN    (again,    subject    to    the   nineteen    (19) 
charactei      limit  if      from   the      keyboard)  ,      as      shown    in      the 
following   example. 


KB  — 
VR  — 


CARL  VINSON    <cr> 
"CARL  VINSCN" 


Once  the  correction  to  the  ship  name  has  been 
irade,  ycu  will  again  be  shown  the  view  in  Figure  3.15  to 
confirm  the  names  cf  the  battle  group  units.  For  the 
purposes  cf  our  example,  we  will  assume  that  it  is  now 
correct,  and  you  should  enter  "RETURN,"  (as  described 
earlier) . 

Should  ycu  make  an  error  in  entering  a  CARRIAGE 
EETUBN  or  the  numter  of  the  ship  that  is  incorrectly 
spelled,  ycu  would  see  the  following  on  the  screen,  after 
which  ycu  can  make  ute  correct  entry. 
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PRESS  CARRIAGE  RETURN  IF  THE  LIST  IS  CORRECT,  OR  IF  NOT,  THE 
APPROPRIATE    TWO    DIGIT    NUMBEE 

Since  the  listing  was  correct,  and  ycu  entered 
CARRIAGE  RETURN,  ycu  will  new  see  an  explanation  of  the 
operations  of  the  system  with  respect  to  the  units  in  your 
battle   group.  This     information    is    shown   in      Figure    3. 17. 

The  display  of  this  view  also  signifies  that  the  master 
database  is  being  searched  for  your  units  and  their  capabil- 
ities are  being  filed  in  a  battle  group  database.  The 
units  net  in  the  naster  database  will  be  "flagged"  for 
manual   insertion  of    their   capabilities   information. 


I 

I       THE 

EATAEASE    IS 

BEING    SEARCH 

TO 

ASSE 

MBLE 

THE 

! 

INFORMA-          I 

TICN 

ECR    YOUR    BATHE    GROUP. 

PLEASE 

WAIT 

FOR 

AN 

ACK-             I 

I       NOSLEEGEMENT    CF 

SEARCH    CCMPI 

ETION    PRIOR    TO    ENTERING 

I       ANY 

fUETHER     DATA 

YOU    MILL 

BE    TOLD 

IF    THERE 

IS 

A    PRC-       | 

I       BIEM 

IN    LOCATING 

ANYTHING    AEOUT 

YOUR 

UNITS. 

I 

*  #* 

FBESS    RETURN 

TO 

CONT 

INUE 

**# 

I 

i 

Figure   3.17        Haster  Database    Search   in   Progress. 


When  ycu  are  ready  tc  continue,  enter  CARRIAGE  5ETURN  (as 
described  earlier).  You  should  notice  a  short,  delay  in  the 
screen   refreshing   as   the   master      database    is   searched.  If 

there  is  no  difficulty  in  searching  the  master  database, 
then  the  next  query  you  should  see  is  to  determine  which 
unit  will  function  as  "ZZ."  (This  is  discussed  under  Battle 
Group   Position    Determination.)  If      a   ship   requires    manual 

capability  informaticn  entry,  then  you  will  be  so  informed. 
Manual  capability  insertion  is  the  subject  of  the  next 
sec ti en. 
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c.      Manual    Entry  of    Capabilities 

As  we  designed  into  our  example  battle  group, 
DSS  CALIFCBNIA  was  net  a  unit  in  the  master  database.  That 
teing  the  case,  ycu  would  see  the  information  shown  in 
Figure  3.18,  indicating  the  units  not  in  the  master  data- 
rase,    and   requiring    iranuai    capabilitiy   entry. 


TEE    FCL1CWING    ONUS    WEBE    NOT    IN    THE    MASTER 
ANE    WILL    REQUIRE    MANUAL    DATA    ENTRY. 


DATABASE 


CAIIECBNIA 


SINC 

INFO 

HAND 

OF  S 

PEES 

THE 

FIVE 

CHIT 

THIS 

CCNT 


E  TH 
SEAT 

ALLY 
EKSC 
ENTE 
FCEM 

BIN 
ICAL 

EEC 
ISUE 


ESE  UNIT 
ION  BEG  A 
.   THIS 
FS  AND  W 
E  EQUIPM 

OF  EASY 
UTES  PER 

FOR  THE 
ISION  SU 
.  ENTER 


S  ARE  NO 

BEING  TH 

WILL  REQ 

SAEONS  S 

ENT  SELE 

TC  USE 

SHIP  TO 

CEERATI 

PPCRT  SY 


YES 


A 


T  I 

EM 

UIR 

YST 
CTI 
MEN 
EN 
CN 
STE 
ND 


N  THE 
WILL 
E  A  K 
EMS  0 
ON/AS 
US. 
TER  T 
Cr  TH 
M.  W 
THE  F 


MASTEB  DATABASE.  THE 
HAVE  TO  EE  ENTERED 
NOWLEDGE  OF  THE  TYPE 
NBOARD.   YOU  WILL  BE 
SIGNMENT  OPTIONS  IN 
IT  TAKES  APPROXIMATELY 
HE  DATA.   THIS  DATA  IS 
E  OTHEB  MODULES  OF 
HEN  YOU  ABE  BEADY  TO 
IBST  MENU  WILL  APPEAB. 


Figure  3.18    Units  Hot  in  the  Master  Database 


You  must  enter  this  icformaticD  for  CALIFORNIA  in  crder  for 
the  system  database  tc  be  complete.  when  ycu  are  ready  to 
contirue,  enter  the  following: 


KB 
VR 


YES         <cr> 

"Affirmative" 


If   ycu      shculd    enter   anything      other   than   the      YES    response, 
you    will   see  the   following. 

PIFASE    ENTEB    YES    OR    NO 


82 


Rhen    ycu  are  ready,    and   have   the   required    inf ormaticn,    enter 
YES    as   shewn  above.  Wa  will      now    follow   the  sequencing   of 

nanual   data   entry  for  OSS   CALIFORNIA. 

O)  Hull  Number  Determination.  Determination 
of  the  ship's  hull  number,  particularly  with  respect  tc  the 
ship    type,    is   very   important   to   the   system.  The   query   for 

this    information  is    shown   in   Figure    3.19. 


FOB    CALIFORNIA 


~\ 


I   ???  WHAT  IS  HER  HDLL  NUMBER  ???   (MAXIMUM  CF  SIX  CHAR- 

|       ACTERS   E.G.  SSN688,  DD980,  FF1075,  ETC.) 

I 


Figure   3.19        Query  —    Hull   Number   Determination. 


This  entry  from  the  keyboard  is  self- 
explanatory,  remembering  that  there  can  be  NO  blanks  or 
spaces  in  the  hull  nucber  as  shown  in  the  examples.  Figure 
3.20  shews  the  keyboard  entry  for  CALIFORNIA  as  well  as 
examples    for  other    ship   types. 


CALIFORNIA 


SUBMARINE 

FRIGATE 

OILER 


CGN36       <cr> 


SSN688  <cr> 
FF1078  <cr> 
AO1077    <cr> 


Figure   3.20        Hull   Number   Entry   From   the   Keyboard, 
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The      keyboard      entries   contrast      tc      ^hcse 
mads    by    voice.  The  examples   shown   in   Table   I    are   extracts 

of   th€    irfcrmaticn   contained   in    Appendix    A. 


SEIE-  1YFE 

SSN 

CV 

CVN 

CG 

CGN 

EC 

DDG 

FF 

FFG 

20  E 

AOR 

EE 

AFS 

BO 

TABLE    I 
Ship  Type   by   Voice 


SAMPLE    VOICE    COMMAND 

"S  ubmarine" 

"Aircraft  Carrier" 

"Nuclear  Aircraft  Carrier" 

"Guided  Missile  Cruiser" 

"Nuclear  Guided  Missile  Cruiser" 

"D  estrcyer" 

"Guided  Missile  Destroyer" 

"F  rigate" 

"Guided    Missile    Friaate" 

"Fast   Combat    Support    Ship" 

"Replenishment   Oiler" 

"Battleship" 

"Combat   Stores    Ship" 

"Fleet   Oiler" 


For  the  purposes  of  our  example,  Figure 
3.21  shews  the  vcice  input  for  the  hull  number  of 
CALIFORNIA.  Should   you      make   an    error   in      entering    either 

response,    ycu   will    see  the    view   in   Figure    3.22. 


"Nuclear    Guided    Missile   Cruiser"    "Three"    "Six" 
"Carriage   Return" 


Figure    3.21        Hull    Nuaber    Entry   by   Voice. 
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figure    3.22        Response   Error   Identification. 

(2)      Grou£      Assignment   Determination.  One     of 

the  aduiristra ti ve  elements  of  the  unit's  database  is  its 
Cruiser-Destro yer/Carrier  Group   assignment.  This    informa- 

tion in  the  system  is  not  applicable  to  either  Submarines  or 
Service  Force  units,  therefore,  if  the  ship  type  indicated 
in  the  hull  number  cf  a  unit  identifies  it  as  one  of  these 
typss,    this   query   will  not    be   presented.  For   our    example, 

the    query    for  the    grcup   assignient    is   shown   in  Figure    3.23. 


FOB    CALIFORNIA 

???    IC    SHICH    CRUDESGRU    OE    CARGSa    IS    SHE    ASSIGNED    ??? 

(1,    3,    5,    7,     or    9  (HIDPAC)) 


Figure   3.23        Query   -  Group   Assignment. 


While  the  query  in  Figure  3.23  shews 
"9  (MIEPAC)  ,'f  as  a  grcup  option,  only  the  "9"  is  the  appro- 
priate respense  if  applicable.  Your  response  should  be  the 
appropriate   CRUDESGRC/CARGR U      number.  If      CALIFORNIA    were 

assigned   tc   CRUDESGRO   3,      the    following    is    the   format    of   the 
correct   entry. 

KB      —  3         <cr> 

VR      —         "Three"      "Carriage   Return" 
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Should  ar  error  occur  in  making  your  response,  the  following 
will    te    displayed   on   the  screen. 

LIMIT    YOUE    ANSWEE   TC    1 ,    3,    5,    7,    or   9 

***    PRESS    RETURN    TC    CONTINUE    *** 

When    ready,    continue    as    discussed   in   sarlier   examples. 

(3)       Squadron      Assignment    Determination.  With 

all  destroyer  and  frigate  ship  xypes  (as  indicated  in  the 
hull  uunber),  the  next  guery  addresses  the  destroyer 
sguadron   assignment.  This   guery   will   not   be  presented   for 

non  DC/DEG/FF/FFG  ship  types.  The  guery  is  shown  in  Figure 
3.24. 

Your  response  to  this  guery  can  be  any  one 
or  twc  digit  number  reflective  of  the  unit's  DESRON  assign- 
ment. For  our  example  battle  group  unit,  CALIFORNIA,  you 
would  not  get  this  guery,  as  the  CALIFORNIA  is  a  CGN,  a  unit 
not  assigned  to  a  DESEON.  A  sample  response  to  this  guery 
for    PAUL    F    FOSTER   would    be    as    follows. 


FOR    PAUL    F    FOSTER 

??    10    KH1CH    DESRON    IS    SHE    ASSIGNED     (IF    APPLICABLE)     ?? 


Figure  3.24        Sguadron   Assignment   Determination. 


KE  —  23      <cr> 

VE  —        "T*c"    "Three"    "Carriage   Re-urn" 
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Should   ycu    make    an    error  in    entering   your   DESRON    assignment, 
you    will    see  the   following: 

YCU    WILL    HAVE    TC    REENTER    THE    DESRON    ASSIGNMENT 

***    PRESS    RETURN    TO    CONTINUE    *** 

When  you  are  ready,  enter  CARRIAGE  RETURN, 
then  the  query  shown  in  Figure  3.24  will  be  presented,  and 
you    should    reenter    ycur   response. 

(4)       Primary  /Secondary  Missile  System 

Determination.  The     determination        of        the 

primary      and      secondary      missile        system      capabilities      are 
addressed  together.  Recognize    that   a    ship    may    have   both   a 

primary   and   secondary  system,      only   a    primary   system,      cr   no 
missile   system    capability   at      all.  Figure    3.25    (adjusted) 

shows    the   available    nrissile    system   options.  The   following 

will      precede      the      menu  for      determination      of      the      ship's 
primary    irissile    systeir   capability.  We    will   use    CALIFORNIA 

for   the    sample. 

If  the  ship  has  no  missile  system,  then 
you    wculd    select   "NOT    APPLICABLE,"      entering    "0".  With    no 

primary   missile      system   indicated,         you   will     not    be      asked 
about   anj   secondary   capability.  Should    ycu  indicate  that 

the    ship   dees  have    a    primary   missile    system,      then    ycu    would 
again    receive  the   query   shown      in  Figure   3.25.  This    time, 

the    query    wculd    be    prefaced    with   the   following  statements. 

EOR    CALIECFNIA 

111    WHAT    IS    HER    SECONEARY    MISSILE    SYSTEM     (IF    APPLICAELE)     111 

In  all  cases,  when  responding  tc  these 
queries,  ycu  would  indicate  the  appropriate  system  for  that 
sbip  ty  entering  the  number  tc  the  left  of  that  capability. 
Fcr    CAIIFCENIA,      which   has    enly      an    SM1-MR   system,      we    wculd 
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FOB    CALIFORNIA 


0 
1 
2 
3 
4 
5 
6 


???  WHAT  IS  HER  PRIMAFY  MISSILE  SYSTEM  ??? 

*  MISSILE  SYSTEM  OPTIONS  * 

NOT  APPLICABLE 

NATO  SEASFARROW  MISSILE  SYSTEM  (RIM-7) 

STANDARD  MISSILE  SYSTEM  (SM1-ER)   (RIM-67) 
BASIC  POIKT  DEFENSE  MISSILE  SYSTEM  (RIM-7 

STANDARD  MISSILE  SYSTEM  (SM2-MR)   (RIM-66C 

STANDARD  EISSILE  SYSTEM  (SM1-MR)   (RIM-66E 

STANDARD  MISSILE  SYSTEM  (SM2-ER   (RIM-67E 


SELECT  0,  1,  2,  3,  4,  5,  cr  6 


Figure   3.25        Query  Henu  -   Hissile   System  Options, 

respond    tc    the    query   regarding   the   primary    missile   system   as 
follows. 

KB      —  5        <cr> 

VR      —    "Five"    "Carriage    Return" 

Since  we  indicated  that  CALIFORNIA  has  a 
primary  irissile  system,  then  the  query  for  her  secondary 
missile  system  capability  will  be  presented.  CALIFORNIA  has 
no  secondary  missile  system,  thersfore,  the  response  would 
ke   as    fcllcws. 

KB      —  0    <cr> 

VR      --    "Zero"    "Carriage   Return" 

Should  an  error  occur  in  entering  git  her 
cf  these  values  (pri&ary/seccndary  capability) ,  you  will  see 
the    following. 

YCD    MCST    LIMIT    YOUB    CHOICES    TO    0,     1,     2,     3r    4,     5,     cr    6 
***    PRESS    RETURN    TO    CONTINUE    *** 
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Continue  as  discussed  earlier,  and  the  appropriate  preface 
(primary/secondary)  along  with  the  missile  system  options 
will    appear.        Make    your  selection   as    demonstrated. 

(5)      H§.£I£2S     Capability        Determination.  The 

next  query  with  which  you  will  be  presented  will  address  the 
ship's   Harpoon      weapons   system      capability.  The      query   is 

shown    in   Figure    3.26. 


FOB    CALIFORNIA 

???    IS    THIS    UNIT     EARPOON    CAPABLE    ???  (YES    OR    NO) 


Figure    3.26        Query   -   Harpoon   Capability. 


The  intent  of  This  capability  determina- 
tion is  tc  comfirm  net  only  that  the  ship  is  capable  of 
having  the  Harpoon  system,  but  also  has  the  weapons  onboard. 
As  we  will  see  later,  this  is  not  a  "one  time"  entry. 
Within  the  STATUS  module  is  a  capability  to  CHANGE  any  item 
in  the  ship's  database,  and  therefore  allow  for  a  real  time 
maintenance  on  onboard  weapons.  Your  response  would  be  the 
following,    as  appropriate. 


KE      —  YES      <cr> 

VR     --        "Affirmative" 


or  NO        <cr> 

or        "Negative"    " 


If  you  make  a  mistake  in  entering  your  YES/NO  response,  you 
will  see  the  following,  after  which  you  simply  reenter  your 
response . 

PLEASE    ENTER    YES    OR    NO 


as 


(6)  ?ri  nary  /Secondary  Air  Search  Eadar 
Determination.  Similar  to  the  missile  system 
capability  determination,  the  same  menu  is  utilized  for 
deterainatior  of  the  primary/secondary  air  search  radar 
capability.  Figure  c.27  shows  the  composition  of  the  menu. 
As  yet  have  seen  before,  the  menu  will  be  prefaced  ty  the 
appropriate  declaration  of  which  capability  (primary  or 
secondary)  is  being  solicitad.  The  query  for  the  ship's 
primary  capability  is  reflected  in  Figure  3.27.  As 
CALIFORNIA  has  an  AN/SPS-48C,  the  following  would  te  entered 
in  response  to  this  guery. 

KB  —  1   <cr> 

VB   —  "One"  "Carriage  Return" 


FOE  CALIFORNIA 

???  WHAT  IS  HER  PRIMARY  AIR  SEARCH  RADAR  ??? 
*  AIB  SEARCH  RADAR  OPTIONS  * 

6  —  AN/SPS-37A 

7  —  AN/SPS-52  | 

8  --  AN/SPS-4  0  | 

9  --  AN/SPS-39  | 
1 0    —  AN/SPY- 1                                I 


0 

— 

NONE 

1 

~ 

AN/SPS-48C 

£ 

— 

AN/SPS-49 

3 

— 

AVSPS-65 

a 

— 

AN/SPS-58 

b 

— 

AN/SPS-43A 

SELECT    CNE   OF    THE    ilEOVE 


Figme    3.27        Query   Menu  -   Air   Search   Radar   Options. 

Once  the  primary  air  search  radar  has  been 
determined,  the-  query  for  the  ship^s  secondary  capability 
will    te   presented.  As   you   have   seen  before,      if    ycu    indi- 

cate that  the  ship  has  NO  primary  capability,  then  the  query 
for  the  secondary  cafability  will  not  be  presented.  If  you 
indicate  a  primary  capability,  then  the  following  preface 
will    appear. 
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FOR    CALIFORNIA 

WHAT    IS    HER    SECONEAEY    AIR    SEARCH    RADAR     (IF    APPLICABLE) 

The  manner  in  which  tfce  capability  is  entered  is  the  same 
for  the  secondary  capability,  and  is  shown  in  the  following 
example,  indicating  CALIFORNIA  has  an  AN/SPS-40  for  a  secon- 
dary   air   search    radar. 

KB      —  8        <cr> 

VR      --        "Eight"    "Carriage   Return" 

Should  an  error  occur  in  entering  either 
the  primary  or  secondary  capability,  the  the  warning  shewn 
in  Figure      3.28    will      be  presented.  On    receiving      such   a 

warning,  simply  enter  CARRIAGE  RETURN,  and  the  appropriate 
preface,      followed    by  the  menu      will   appear.  Then   reenter 

your    response. 


YOD    WILL    HAVE    TO    REENTER    YOOR    RESPONSE    FROM    THE    MENU  | 

OPTICAS.  1 

I 
***    PRESS    RETURN    TC    CONTINUE    *** 


Figure    3-28         Warning   -  Response   Not   From   Menu    Options. 


(7)       Surface         Search        Radar         Determination. 
Figure    3.29    shows      the   query    you    will    be      prespnted    with    for 
the    determination  of   the  ship's   surface   search  radar. 

CALIFCENIA    has    an   AN/SPS-10    onboard,    therefore,      the   correct 
response   would    be  as    fellows. 


KB      — 


<cr> 
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FC5  CALIFORNIA 

???  WEAT  IS  HER  SURFACE  SEARCH  RADAR  CAPABILITY  ??? 

*  SURFACE  SEAFCH  RADAR  OPTIONS  * 

0    —  NONE 

2  —  AN/BPS-15 

3  —  fiN/SPS-10 

4  —  AN/SPS-55 

5  --  AN/SPY-1 

SELECT    CNE   OF    THE    ABOVE 


figure   3.29        Query    —   Surface   Search   Radar. 

VR      --      "Three"    "Carriage   Return" 

(8)       Prig ary /Secondary        Fire  Control        Sadar 

Determination.  Particularly  important  for  the 
combatants  (non-Service  Force  ships)  is  the  specification  of 
their      fire     control      radar      capability.  As      the      system 

addresses  toth  primary  and  secondary  capabilities,  the 
procedures  for  entering  this  information  are  similar  to 
those  utilized  with  missile  systems  and  air  search  radars. 
Figure  3.30  shows  the  menu  options  for  fire  control  radars. 
The  guery  for  determination  of  the  primary  capability  is  is 
reflected    in  Figure    3.30. 

Your  response  would  be  the  number  corre- 
sponding to  the  system  you  desire.  If  you  indicate  that 
the  ship  dees  not  have  a  primary  capability,  as  you  have 
seen  tefcre,  you  will  not  be  presented  with  the  guery  for 
the  secondary  capability.  A  correct  response  would  look 
like   the   following. 

KB      —  2         <cr> 

VR      --        "Two"    "Carriage   Return" 
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FCB    CALIFORNIA 

???    WEAT    IS     HER    PRIMARY    FIRE    CONTROL    RADAR     (IF    APELI- 
C  AELE)     ??? 

*    FIRE    CONTROL    RADAR    OPTIONS    * 

0  —    NONE  10    —  MK-99 

1  --    HK-S1  11    —  MK-74 

2  —    AN/SEG-55A  12    --  MK-68 

3  —    AN/SEG-49  13    --  MK-92 

4  —    AN/SEW-2  14    —  AN/SPG-53 

5  --    HK-40  15    --  AN/SPG-60 

6  —    AN/SEG-51  16    —  MK-13 

7  --  MK-7  17  —  AN/SPQ-9 

8  --  MK-76  18  —  AN/SPG-35 

9  —  MK-56 

SEIECI  CNE  OF  THE  ABOVE 


Figure  3-30    Query  Henu  -  Fire  Control  Radar  Options. 

If  you  indicate  a  primary  capability,  the 
query  fcr  the  secondary  capability  will  appear  with  the 
following  prefacing  the  menu  options. 

FOR  CALIFCENIA 

WHAT  IS  EFR  SECONDARY  FIRE  CONTROL  RADAR  (IF  APPLICABLE) 

The  response  for  the  secondary  capability 
is  of  the  same  format  as  the  primary.  Should  an  error 
cccui  in  entering  ycur  response,  you  will  see  the  warning 
shown  in  Figure  3.28.  As  was  discussed,  when  ready,  enter 
CARRIAGE  RETURN  and  the  appropriate  preface  and  menu  will 
appear.    Reenter  your  response. 

(9)   HHF^HF   Radio   Capability   Determination. 
One   cf   the  important  capabilities   of   the  system   is  to 
display  the  communications  links   within  the   battle  group. 
This  is  dene  in  the  CCMMS  module.    The  graphics  displays  of 
the   nets  is  color   coded  to   show   not   only  the   relative 
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distance  between  participating  units,  but  also  their  respec- 
tive ra<3ic  requirements  based  en  mission  area.  The 
dynamics  of  the  status  of  communications  equipments  makes 
this  a  gcod  indicator  of  C3  performance.  The  base  for  the 
determination  of  the  available  radios  onboard  is  the  attri- 
tion applied  to  installed  numbers  of  these  radios.  This 
number  of  installed  radios  is  the  value  desired  in  this 
query.  The  system  will  differentiate  between  UHF  and  HF 
radios.  The  guery/response  sequence  is  straightf oward. 
The  query  for  the  number  of  installed  UHF  radios  is  shewn  in 
Figure   3  .31 . 


FCB    CALIFORNIA 

???    HCW    MANY    UHF    RADIOS    DOES    SHE    HAVE    ONBOARD    ??? 
(RANGE    1    TO    9  9) 


Figure    3.31        Query    -   DHF   Radio   Capability. 


Identical  to  the  format  for  the  UHF  guery, 
the  query  for  the  nunters  of  installed  HF  radios  is  shewn  in 
Figure   3.32. 

The  response  to  either  if  these  queries  is 
cf   the   same    format    arc   an   example    is   as   follows. 

KE      —  15  <cr> 

VB     —        "Cne"   "Five"    "Carriage   Return" 

If  ycur  response  is  net  within  the  range  specified  (1  -  99) , 
then  ycu  will  see  the  warning  shown  in  Figure  3.33  on  the 
screen. 
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FOB    CiLIJORNIA 

???    HCW    MANY     HF    RADIOS    DOES    SHE    HAVE    ONBOARD    ??? 
(BANG!    1    TO    99) 


Figure    3.32        Query  -   HF  Radio  Capability. 


YOU    WILL    HAVE   TO    REENTER    THIS    NUHBER 
***    PRESS    RETURN    TC    CONTINUE    *** 


Figure  3.33        FBHOR    in    Entering   Integer  value. 


After    ycu   enter    CARRIAGE   RETURN,         the    applicable    query    will 
reappear  and  you  can    reenter    ycur   response. 

(10)       Satellite  Communications  Ca  pability 

Determination.  To   complete      the  database      for 

the   communications      capabilities   of    the      ship,      you      need  to 
identify   the     ship's    satellite      ccmm   capability.  This   is 

very  straightf oward ,  and  the  query  is  shown  in  Figure  3.3U 
(adjusted)  .  To  give  the  ship  a  capability  indicated  in  the 
trenu,  siirply  enter  the  number  corresponding  to  the  equipment 
desired. 


If    you  desire  to      indicate   that    CALIFORNIA 

has    an    AN/wSC-3    onboard,      ycur  response    would  look    like   the 
following   example.. 

KB     —  1      <cr> 
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FCB    CALIFORNIA 

???    WHAT    SATELLITE   COMMUNICATIONS    CAPABILITY    DOES    SHE 
HAVE    ??? 

0  —    NCNE 

1  —     AN/WSC-3 

2  —    OE-82 

SEIECT    0,1,    CR    2 


Figure  3.34    Query  -  Satellite  Communications  Capability. 

VR   —   "One"  "Carriage  Return" 

Should  you  make  an  error  in  entering  this 
response,  then  the  warning  shewn  in  Figure  3.28  will  appear. 
After  ycu  enter  CARRIAGE  RETURN,  the  SATCOM  menu  will  reap- 
pear, and  ycu  can  reenter  ycur  response. 

(11)  Gun  Syste  m  Capability  Determination.  The 
next  input  to  the  ship(s  database  is  her  gun  weapons  system 
capability.  Figure  3.35  (adjusted)  shows  the  query  menu 
with  the  available  gun  options. 

CAIIFCRNIA  has  a  5"/54  MK45  gun.  The 
following  is  an  example  of  how  we  would  enter  this  informa- 
tion. 

KB   —  5    <cr> 

VR  --   "Five"  "Carriage  Return" 

The  warning  shown  in  Figure  3.28  will 
appear  if  ycur  response  is  not  within  the  range  of  the  menu 
options  (0  -7).  After  ycu  enter  CARRIAGE  RETURN,  the 
guery  menu  will  appear  and  you  can  reenter  your  response. 
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FOB    CALIFORNIA 

???    WHAT    IS    HER    GON    WEAPONS    SYSTEM    CAPABILITY    ??? 


0 
1 

2 
3 
4 
5 
6 
7 


*    GON    SYSTEM    OPTIONS    * 

—  NCT    APPLICABLE 

—  16"/50    (406    mm)     MK7       MOD   0 

—  5"/38    (127    mm)     MK12    MOD    1 

—  2mm/70  MK4 

—  5"/54    (127    aim)     MK42 

—  5"/54     (1  27    mm      MK45 

—  3"/50    (76    mi)        MK22 

—  76   mm     (OTO    &ELARA) 


SELECT    ON   OF    THE    AEOVE 


Figure    3.35        Query   -   Gun   System   Options. 

(12)       PHAIANX      Ca^abilit^  Determination .           The 

query   shewn      in    Figure   3.36      requests  the    number      of   PHALANX 

systems   the   ship      has  onboard.           The  number     of    systems   can 

range    ficm    zero    (0)     through    normally,  four    (4). 


FCF    CALIFORNIA 

???    HOW    MANY    PHALANX    SYSTEMS    DOSS    SHE    HAVE    ??? 


Figure    3,36        Query   -   PHALANX   Capability. 


To    indicate   that    CALIFORNIA      has   three    (3) 
PHALANX   systems    onboard,      the    following   entry    would   be    made. 
Should   an      error  occzt     in    making      this   entry,        the   warning 
shown    in   Figure    3.33   will  appear,    and   when    you  continue,   the 
guery   will    again  come   up,   and    you   cna   reenter    your   response. 


KB      — 


3      <cr> 
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VR       — 


"Three"    "Carriage   Return" 


(13)  TOKAHAWK  Capability.  Determination.  While 
the  TCMAEAWF  weapons  system  is  relatively  new  to  the  fleet, 
this  capability  will  become  increasingly  available  in 
upcoming  years.  To  ensure  that  this  DSS  has  the  ability  to 
display  the  TOMAHAWK  capability,  this  solicitation  for 
information   will  be    presented.  The      query   shown    in    Figure 

3.37    requests  the  ship*s  TOMAHAWK   capability.  In   the   case 

of   our    example,         CALIFORNIA,      she   does   not      have    this   capa- 
bility. 


FCE    CALIFORNIA 

111    IS    SHE    TOMAHAWK    CAPABLE    ???  (YES    OR     NO) 


Figure    3,37        Query   -  TOMAHAWK   Capability. 


There  is  a  difference  in  the  intent  of 
this  guery  as  opposed  to  that  of  the  HARPOON  capability. 
With  ICMAHAWK,  it  is  assumed  that  since  few  ships  have  this 
capatiiity,  those  that  do  will  have  the  weapons  onboard. 
Therefore,  a  "YES"  response  to  this  query  should  mean  that 
the    ship   in   question    has  not      only   the   capability,       tut   also 


the      weapons. 

applicable. 

KE   — 

VB   — 


Your  response  would   be   the  following  as 


YES   <cr>    or 

"Affirmative"  or 


NO        <cr> 

"Negative" 


Should   an   error    occur   in   making   this   response,    you    would   see 
the    fcllcwing  on   the    screen. 

PLEASE    ENTEE    YES    OR    NO 
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(14)  Helicopter  Capability  Determination.  The 
helicopter,  as  a  surveillance  vehicle  or  a  weapons  platform 
is   becoming     invaluafcle   to    the      battle   group.  The   query, 

shown    in   Figure    3.38,   requests   information   on  the    helicopter 
cajDafcilit^   cf  the   ship   in      guestion.  The   four   helo   types, 

present   in    a  battle    group  are     shewn  as    options.  Cr.ce   the 

capability   has    been    affirmed,    then   you   will   be   asked   whether 
the   the   ship  actually   has   its    detachment   onboard. 


FCR    CALIFORNIA 

???    WHAT    IS    HER    HELICOPTER    CAPABILITY    ??? 
*    HELO    OPTIONS    * 

1  —  NOT  CAPABLE 

2  —  HC  DET  (CH-3) 
2   —  HS  DET  (SH-3) 
U  —  HC  DET  (CH-46) 
5  —  HSL  DET  (SH-2) 


Figure    3.38        Query   -  Helicopter  Capability    Determination. 


For    CALIIOENIA,    which   has   a    LAMPS   capability,      your    response 
would    be   the  the   following. 

KB      —  5         <cr> 

VR      —      "Five"   "Carriage   Return" 

Once  the  capability  has  been  determined  to 
exist,  jou  will  receive  a  query  regarding  the  embarcation 
status   of  the      detachment.  This   query   is      tailored   tc   the 

type    cf      capability    you   gave      the  ship.  For      our    example. 

Figure    3.39    shows   the  query. 
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1 

???  DOES  CALIFOENIA  HAVE  HER  LAMPS  DET  ONBOARD  ??? 
(YES  CE  NO) 

Figure  3.39    Cnery  -  LAHPS  Embarcation  Status. 


As  was  mentioned,   this   query  is  tailored 

to  the  type  of  capability  you  gave  the  ship.  If  you  had 

indicated  that  the   ship  had  an  HC   DET  (CH-46)  capability, 

then  the   fcllowing  viculd  be   the  query  for   the  embarcation 
status. 

???  DCES  <SHIP>  HAVE  HER  "CH46"  DET  ONBOARD  ??? 

(YES  CR  NO) 

There   are  similar   iratches  for   each   capability  listed  in 
Figure  3.38. 

At  this  point,  an  additional  capability  of 
the  system  needs  to  te  addressed.  We  will  discuss  in  the 
STATES  module  operaticns,  the  capability  you  will  have  to 
change  any  item  in  the  ship's  database  once  the  battle  group 
has  been  established.  That  capability  utilizes  tha  same 
menus  and  prefaces  as  does  the  module  in  which  we  are 
working.  While  that  capability  will  be  covered  in  mere 
depth  later  (under  STATUS  Module  Operations),  reference  will 
regularlj  be  made  to  these  sections  for  explanation  of  the 
gueries  and  appropriate  responses  with  respect  to  the  menus. 
When  dealing  with  the  helicopter  embarcation  status  CHANGE 
ONLY,  there  is  a  warning  that  could  appear  if  you  attempt  to 
embark  a  helicopter  detachment  on  a  ship  to  which  there  has 
teen  given  NO  helo  capability.  In  this  case,  the  warning 
shown  in  Figure  3.40  will  be  presented. 
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BASED  CN  THE  INFOEKATION  IN  THE  DATAEASE,  THIS  UNIT  IS   | 

NOl  EILC  CAPAELE.   YOU  WILL  HAVE  TO  FIRST  GIVE  HER  THE   | 

CAEAEILITY.  I 

***  PRESS  RETURN  10  CONTINUE  ***  I 


Figure  3.40    Warning  -  Ship  Not  Helo  Capable, 

This  situation  is  not  possible  when 
working  in  the  BUILD  module,  which  we  are  discussing,  as  you 
will  ret  be  gueried  en  the  embarcation  status  of  a  ship  to 
which  ycu  gave  no  helc  capability. 

Shculd  an  error  occur  in  making  the 
response  regarding  the  capability,  the  warning  showr.  in 
figure  3.28  will  appear.  After  you  continue,  you  will 
again  be  presented  with  the  menu,  and  can  reenter  your 
response.  Should  an  error  occur  when  you  are  making  your 
response  regarding  the  embarcaticn  status,  you  will  see  the 
following  on  the  screen. 

PLEASE  ENTER  YES  OR  NO 

At  this  point,  simply  reenter  yor   YES/NO  response. 

(15)  Sonar /I  VD  S  Capability.  Determination.  The 
guery  for  the  ship's  sonar  capability,  shewn  in  Figure  3.41, 
will  net  be  presented  for  the  Aircraft  Carriers,  or  Service 
Eorce  ships.  Also,  the  assignment  of  the  sonar  capability 
is  important  because  in  the  SENSOR  module,  some  of  the 
sonars  are  "flagged"  as  being  capable  for  convergence  zone 
operations,  and  that  capability  will  be  displayed  if  you 
indicate  that  these  conditions  exist. 
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FOB    CALIFORNIA 

???    WHAT    IS    HER    SONAR    CAPABILITY    ??? 
*    SONAR    OPTIONS    * 

0  —    NOT    CAPABLE  6    —  AN/BQS-12 

1  —    AN/3QC-5  7    —  AN/SQS-23 

2  —    AN/BQS-15  8    —  AN/SQS-26 

3  —  AN/BQC-2  9  —  AN/SQQ-23 
U  —  AN/BQS-6  10  —  AN/SQS-53 
5    —    AN/BQB-7  11    —  AN/SOS-56 


Figure   3.11        Query  -  Sonar   Options. 

You  would  indicate  the  sonar  capability  be 
entering  the  number  corresponding  to  the  equipment  desired. 
For  CALIFORNIA,  which  has  an  AN/SQS-53  sonar,  your  response 
would   lcck    like    the    following. 

KB  —  10        <cr> 

VR   —      "One"    "Zero"    "Carriage   Return" 

Should  au  error  occur  in  making  this  response,  the  informa- 
tion shown  in  Figure  3.28  wculd  appear.  When  you  continue. 
Figure  3.41  will  reappear,  and  you  can  reenter  your 
response. 

The  IVDS  capability  determination  is  stra- 
ightfcward,      and  requires   only   a    YES/NO    answer.  The    guery 

for   this   information   is   shown    in    Figure    3.U2. 

CALIFORNIA  does  not  have  this  capability, 
therefore   we  would      enter  NO.  The   response,        in   general, 

wculd   be   the  following   as  applicable. 

KB      --  YES      <cr>  or  NO        <cr> 

VR      --   "Affirmative"        or        "Negative" 
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FCR  CALIFORNIA 

* 

???  DCES  SHE  HAVE  AN  IVDS  CAPABILITY  ???    (YES  OR  NC) 


Figure  3.42   Query  -  IVDS  Capability. 

Should  ycu  make  an  error  in  responding,  you  will  be  directed 
to  enter  your  YES/KC  response  again,  as  we  have  seen 
earlier. 

(16)  TASS  Capability  Determination.  The 
deter iinaticn  of  the  TASS  capability  applies  to  only  to 
submarines,  destroyers,  cruisers  and  frigates.  This  guery 
will  net  te  presented  for  ships  not  in  those  ship  types. 
Figure  3.43  shows  the  composition  of  the  query. 


r — 

FOB 

CALIFORNIA 

i 

???     WHAT    IS 

HER 

TASS    CAPABILITY 

?  ?? 

0  — 

1  -- 

2  — 

NCI    APPLICAEIE 
AN/SQR-19     (IMPROVED 
AN/SQR-18      (TACTASS) 

TACTASS) 

_            _             i 

Figure  3.M3   Query  -  TASS  Capability. 

The  response  to  this  guery  is  the  number  corresponding  to 
the  desired  capability.  CALIFORNIA  does  not  have  this 
capability,  therefore  the  response  would  be  as  follows. 

KB   —  0       <cr> 

VR   —   "Zero"  "  Carriage  Return" 
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Should   an      error  occur      in    making      this   response,  then   the 

warning   shown   in  Figure    3.2€   will   be   presented.  After    you 

continue,      the    TASS    Capability   menu   will   again   be  presented, 
and   ycu   can   reenter    ycur  response. 

(17)       ASW  Rocket/Torpedo  Capability 

Determination.  The   determination      of    the      ASW 

weapons     capability    for     the   units      of   the      battle   group     is 
discussed   tcgether.  These  capabilities    are  not    applicable 

to   aircraft   carriers    and  service   force    ships,      and   therefore 
the    queries     will   not   be      presented    for   those      units.  The 

composition     for  the      guery      for      determination   of      the      ASW 
rocket   capability   is    shown    in    Figure    3.44. 


FCE    CALIFORNIA 

???    WHAT    IS  HER    ASW    RCCKET    CAPABILITY    ??? 

N  —    NOT     APPLICABLE 

A  —    ASROC 

S  —    SUB  HOC 


figure   3.44        Query    -   ASW   Rocket   CApability, 


This  is  the  first  query  menu  that  requires  a  response  that 
is   a    character    and    not   a   number.  Also,    there    is    no    system 

check  of  the  input  ycu  make,  sc,  you  could  give  a  SUBRCC  (a 
submarine      weapon)  to      a    surface      ship.  This      fact      is 

mentioned  net  to  encourage  you  to  do  this,  but  rather  to 
alert  you  to  the  possibility  cf  error  without  system  correc- 
tion. The  response  desired  is  made  by  entering  the  char- 
acter corresponding  to  the  desired  capability.  CALIFCRNIA 
has  an  ASROC  capability,  therefore  the  response  would  be  as 
follows. 
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KB  —  A     <cr> 

VR   --   "ASROC"  "Carriage  Return" 

The  system  looks  for  a  response  that  has  no  numbers  and 
either  the  "Nf"  "A,"  or  "S"  characters.  Should  ycur 
response  net  be  any  cf  those  inputs,  then  you  will  see  the 
warning  shown  in  Figure  3.28.  After  you  continue,  the  menu 
will  te  again  presented,  and  ycu  can  reenter  your  response. 

The  determination  of  the  ship's  torpedo 
capability  is  similar  to  other  queries  you  have  seen.  Tha 
ccmpcsiticn  for  the  query  is  shown  in  Figure  3.45. 


— , 

FCE 

CALIFORNIA 

??? 

WHAT 

15 

C 

1 

2 

HER     IORPE 
~    NOT    APP 

—  MK46 

—  MK48 

DO    CAPABILITY 
LIC ABLE 

??  ? 

Figure  3.45    Query  -  Torpedo  Capability 


Ihe  input  should  be  the  number  corresponding  to  the  desired 
capability.  CALIKRNIA  has  a  MK46  torpedo  capability, 
therefore,  the  correct  response  would  be  as  follows. 

KB   —  1    <cr> 

VR   —     "Cne"  "  Carriage  Return" 

Should  an  error  occur  in  making  this  response,  the  the 
warning  shown  in  Figure  3.28  will  be  presented.  After  you 
contirue,  the  menu  will  be  again  presented  and  ycu  can 
reenter  ycur  response. 


105 


(18)  Maximum  S  peed  Determination  .  The  de sired 
value  of  this  input  is  the  designed  maximum  speed  for  the 
ship    in      question.  In  the      CHANGE    function   of      the   STATUS 

module,  this  value  can  be  kept  current,  as  a  real  time  indi- 
cator of  the  ship's  mobility  capability.  In  the  STATUS 
module,  you  can  adjust  this  value  as  the  situation  dictates. 
The   ccmpcsition    for    the   query   is   shown    in    figure    3.46    . 


FCE    CALIFORNIA 

???   WHAT    IS    EER    MAXIMUM    SPEED    IN    KNOTS    ??? 
(EANGF    1-40    KNOTS) 


Figure  3.46        Cuery  -    Maxiaua   Speed   Capability. 


The  response  to  this  query  should  be  the  ship's  maximum 
speed,  within  the  ranee  given  (1-40  knots).  The  CALIFCEftIA 
has  ar.  unclassified  rraximum  speed  of  33  knots,  and  this 
information   would   be    input    as    follows. 

KB     —  33  <cr> 

VE      —      "Three"    "Three"    "Carriage    Return" 

The  system  will  check  the  input  to  ensure  that  it  is  within 
the    allowable   range.  Should   the      input   not    be    within   this 

range,  the  warning  shown  in  Figure  3.33  will  be  presented. 
After  ycu  continue,  the  query  shown  in  Figure  3.46  will 
again   be   presented,    and   you    can   reenter   your   response. 

(19)       SL^;3  2      Capability.  Determination.           The 

composition   of    the      query    fcr   a   ship's  SLQ-32  capability    is 

shown  in  Figure  3.4*/.  The  required  input  is  a  YES  cr  NO 
response . 
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FOE    C2LIJORNIA 

???    DOES    SHE    EAVE    AN    SLQ-32    CAPABILITY    ??? 
(YIS    CR    NO) 


I 


Figure  3. 47        Query  -   SLQ-32   Capability. 


CALIFCFNIA  does  not  have  this  capability,  therefore  the 
correct  response  would  be  NC.  As  applicable  to  the  partic- 
ular   ship,    the    response    would   be   as   follows. 


KE      — 
Vj      — 


YES      <cr>  or  NO        <cr> 

"Affirmative"  or  "Negative" 


Should  an  error  cccur  in  making  this  response,  the  following 
state itent    will    appear. 

PLEASE    ENTSF    YES    OR    NO 

If   this    cccrrs,    simply   reenter    your   YES/NO    response. 

(20)       Priirary/S  eccndary    Mission   Determination  . 
The    same   menu   is   utilized   for      the   determination    of    both   the 
primary   and      secondary   missions      of   a      ship.  Figure      3.49 

shows  the  composition  of  this  menu.  The  specific  mission 
desired  (primary  or  secondary)  will  be  specified  in  a 
preface    to    the    menu.  The    preface    for   the   determination   of 

the   ship's    primary      lission    is   shown   in      Figure    3.48.  For 

the  purposes  of  this  system,  every  ship  MUST  have  a  primary 
nissicn.  Therefore,   you    will   not    be   allowed  to    enter   "NOT 

APPLICABIE"    for    a   ship's   primary   mission. 
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FCE    CALIFORNIA 

???    WHAT    IS    HEB    SECONDARY    MISSION    ??? 


Figure  3. 50        Query    -   Secondary   Mission  Area. 

This  query  would  be  followed  by  the  mission  options  shewn  in 
figure    3.49.  The   CALIFORNIA   has      a    secondary      mission   of 

ANTI-SUEEARINE  WARFAFE,  therefore  the  correct  input  far 
secondary   mission   area    would   be   as   follows. 

KB      —  ASW  <cr> 

VR   —   "Anti-Submarine  Warfare" 

Ihe  systecr  will  attempt  to  match  your  response  to  these 
options  shewn  in  the  menu,  and  if  there  is  no  match,  an 
error  will  occur.  Should  this  happen,  the  warning  shown  in 
Figure  5.28  will  be  presented.  After  ycu  continue,  the 
applicable  query  will  again  be  presented,  and  ycu  can 
reenter  ycur  response. 

d.   Completion  of  Database  Assembly 

The  complete  sequence  of  capability  menus,  as 
applicable  to  the  ship  types  in  question,  will  be  presented 
for  all  ships  listed  in  the  view  shown  in  Figure  3. 18. 
Once  these  capabilities  have  been  compiled  for  all  cf  the 
ships  in  the  battle  croup,  whether  it  be  done  automatically 
cr  manually,  you  are  ready  to  proceed  to  the  next  phase  of 
Initially  Forming  the  battle  group  database,  determination 
cf  the  positions  of  the  ships.  This  is  the  topic  of  the 
next  section. 
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e.   Establishing  Unit  Positions 

Now  that  the  names  and  capabilities  of  the  ships 
which  will  comprise  the  battle  group  have  been  determined, 
th*  n^xt  information  required  by  the  system  is  the  position 
cf  each  ship.  There  are  generally  three  segments  tc  this 
section  cf  the  BUILD  irodule.  First,  the  unit  which  will  be 
in  "ZZ"  will  be  determined.  Eemember  that  for  the  purposes 
of  this  system,  a  battle  grcup  ship  must  be  at  "ZZ."  Next, 
the  type  cf  coordinate  system  to  be  used  (polar  cr  carte- 
sian), will  be  determined.  finally,  the  positions  for  the 
individual  ships  will  te  input.  Let's  first  look  at  deter- 
ttining  the  unit  to  be  at  "ZZ." 

O)  Determination  cf  "ZZ"  unit.  The  specifi- 
cation cf  the  unit  tc  be  at  "ZZ"  is  critical  to  the  opera- 
tion cf  the  remainder  of  the  mcdules  in  the  system.  It  is 
with  respect  to  this  unit  that  all  of  the  computer  graphics 
coordinates  for  each  ship  will  be  calculated.  The  calcula- 
tion cf  these  graphics  coordinates  is  done  by  the  system  and 
will  be  trarsparant  tc  you.  The  only  information  required 
will  he  the  normally  assigned  ship  positions,  in  terms  of 
the  coordinate  system  you  select,  and  the  system  will  adapt 
these  positions  for  graphics  use.  Irrespective  of  the  coor- 
dinate system  you  specify,  the  position  of  the  unit  at  "ZZ" 
will  have  to  be  input  in  cartesian  coordinates,  as  these 
adapt  mere  readily  tc  graphics  coordinates.  This  query 
will  be  discussed  shortly. 

The  query  shown  in  Figure  3.51  addresses 
the  determination  of  the  unit  to  be  at  "ZZ."  As  you  will 
now  see  throughout  the  remainder  of  this  Decision  Support 
System,  whenever  a  requirement  is  levied  to  name  a  partic- 
ular unit  cf  the  battle  group,  there  will  be  a  current 
listing  of  the  tattle  group  provided  along  with  the  query. 
This  listing   shews  all   of  the   battle  group   units  as   the 
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systeir  has  filed  their  names.  Figure  3.51  shows  the  compo- 
sition of  our  example  tattle  group  to  assist  you  in  identif- 
ying   the    unit   you  desire. 


???    WHICH     UNIT    WILL    FUNCTION    AS    ZZ    ??? 
CAEL    VINSON  PAUL    F    FOSTER  CALIFORNIA 


■~! 


Figure  3.51        Query   -   Name  of   ZZ  Unit. 


The  listing  of  ships  will  always  be  in  three  columns. 
Sines  there  are  only  three  ships  in  the  example  tattle 
group,      there      is   only      one    line.  As      yea   found      when    you 

entered  the  names  of  the  ships  earlier,  the  spelling  of  the 
name  is  critical  fcr  the  system  to  recognize  the  entry. 
Every  tine  there  is  a  request  for  identification  cf  a  unit, 
the  system  will  atteupt  to  match  the  input  name  tc  those  in 
the    tattle    group.  Should    a    match    not    occur,   then    ycu    will 

te  asked  tc  reenter  the  response.  In  order  to  use  the  name 
cf  a  unit,  for  any  function,  it  must  be  first  INSERTed  into 
the  battle  group  datatase,  as  we  have  already  done  for  cur 
three  example  ships.  Even  though  the  listing  shews  "PAUL  F 
FOSTEE,"  the  system  has  been  programmed  to  recognize 
"FOSTER"    as   an    acceptable   version   for    the    same  ship.  This 

is  alsc  true  for  "CABL  VINSON",  as  the  system  will  reccgnize 
"VINSON"  as  the  same  ship.  In  general,  this  applies  tc  all 
ships  with  twe  or  more  words  in  their  names.  The  last  name 
cf  the  ship  has  been  programmed  to  be  an  alternatively 
acceptable      name  representation.  These    differences,        in 

reality,      apply      both   to      keyboard   as      well   as      voice    entry. 
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For    vcicc   entry,      refer   tc    Appendix    A   for   a   detailed   listing 
of   all   legitimate  ship   names      and   their   variations.  Let's 

assign   tie   CARL    VINSCS   to    "ZZ."        The   correct   response    would 
re   as    fellows. 


K3      --      CABL    VIKSCN      <cr>        or 
VH       —       "CARL    VINSON"  or 


VINSON       <cr> 
"VINSON" 


If   there    was  a    mechanical   error      in   making    this   entry,      then 
the    following  alert    would  be   displayed. 

ELEASE    REENTER    THE    NAME    OF    THE    ZZ    UNIT    AGAIN 

If    there    had  not      been   a   match   of   the   input      name   with    these 
of   the   listing     (for    example    if   you   had   input    NIMITZ)  ,        then 


YOUR  ENTFY  FOR  ZZ  NIMITZ  DOES  NOT  MATCH  ANY  OF  THE 
SHIP  NAMES  IN  YOUE  EATTLE  GFOUP.  PLEASE  CHECK  TEE 
SPELLING    AND    COMPLETENESS    OF    YOUR    ENTRY. 

***    PRESS    RETURN    10    CONTINUE    *** 


Figure   3.52        ERBCB   -   ZZ    Naae    Not    Matched   To   Listing. 

you   would   be  shown    the   warning   shown   in    Figure   3.52. 

When  you  continue,  yea  will  again  be  presented  with  the 
query  shewn  in  Figure  3.51,  and  you  can  reenter  your 
response. 

The  next    query    you    will      see  is    for    deter- 
mination  of   the    coordinate    system   to   be    utilized. 

(2)       Determinat  ion    of   Coordinate    System.         There 

are    twe   choices    for    coordinate   systems  on    which   to   bass   ycur 

ship*s    positions,        polar  or      cartesian.  The      query    which 

addresses      the    ccordinate      system   is      shown      in    Figure      3.53 

(adjusted)  . 
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YOU  WILL  NOW  BE  ASKED  FOB  TEE  POSITION  OF  EACH  ONIT  IN 
THE  EATTLS  GROUP. 

???  WCULE  YOU  LIKE  TO  USE  POLAR  OR  CARTESIAN  POSI- 
TIONS ??? 

(ENTEF  "EOLAR"  OR  "CARTESIAN") 


Figure   3.53        Query  -  Coordinate   System. 


The  format  of  the  response  to  this  query,  as  well  as  the 
guery  sequences  which  respectively  follow  each  response 
cpticn    are    shown  in    subsequent      sections.  Should    you   make 

an  error  ir.  entering  the  response  to  the  query  shown  in 
Figure    3.53,   the   following    will    be    presented. 

PLEASE    ESTER    "PCLAF"    OR    "CARTESIAN" 

Bern em her  not  to  include  the  £uctas.  Once  the  type  cf  coor- 
dinate system  has  been  specified,  you  are  asked  for  the 
cartesian  position  of  the  unit  at  "ZZ"  (CARL  VINSON,  in  our 
example)  .        This   query  is   shown    in    Figure    3.54. 


FOB    C2EL    VINSON 

???    WtAT    IS     HER    POSITION     IN    CARTESIAN    COORDINATES    ??? 

(ENIEE    AS    QUAERANT     (R,W,E,G),     SPACE,     X-POSITION,     SPACE, 
Y-EOS1TICN) 

(E.G.    W    030    0S0) 


Figure  3.54   Query  -  Cartesian  Position  of  ZZ  Unit. 
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The  format  cf  the  response  to  this  query, 
and  the  corrections  tc  any  errors  which  ycu  might  encounter 
in  making  this  response,  are  identical  to  these  which  you 
see  for  the  input  cf  a  cartesian  position  for  any  ether 
ship.  Please    refer     tc   the   section   on      Query    Sequences   — 

Cartesian   Coordinate    system,    belcw.  This   will    be   the   only 

time  ycu  are  asked  fcr  the  position  of  the  unit  at  "ZZ," 
unless  ycu  delete  this  unit  frcm  the  battle  group,  in  which 
case  ycu  will  have  tc  reinitiate  the  position  determination 
sequences.  We      will   new    leck      at   the    sequences      which    vou 

will  enccunter  based  on  the  type  of  coordinate  system  you 
specify. 

(3)       Query        Sequences        zz        Polar         Coordinate 

System.  In  response      to      the      query   shown      in 

Figure    3.53,      if    you    desire      to   input   battle    group   positions 

in   pclar  coordinates,        the    correct    format    for      the   response 

would    te   as    follcws. 

KB      —  POLAR    <cr> 

VR      --      "Polar    Cccrdinate   System" 

Once  ycu  have  selected  this  coordinate  system,  ycu  will  be 
sequence  through  each  ship  (less  the  unit  at  "ZZ")  ,  being 
queried  for  its  tearing  and  range  from  "ZZ."  You  will  first 
te  asked  fcr  the  ship's  bearing  from  "ZZ, "  in  degrees  true. 
Next,  ycu  will  te  asked  for  the  ship's  range  frcm  "ZZ,"  in 
YARDS .  After      you   have  entered      a   ship's      position,      that 

position    will   be      presented    tc    you    for      confirmation.  The 

initial    cuery  is   shown   in   Figure    3.55. 

If  PACL  F  FOSTEH  were  bearing  090  degrees  true  frcm  "ZZ," 
then    the   correct  response  tc   this   query    would   be    as    follows. 

KB      —  090  <cr> 

VB      --        "Zero"   "Nine"    "Zero"    "Carrrago    Return" 
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FOB    PSUL    F    FOSTER 

???    WHAT     IS     HER    BEARING    AND    RANGE    FROM    ZZ     ??? 
???    EIARING    ??? 
(EKIES    AS   THREE    DIGITS    000-359) 


Figure  3.55        Cuery   -   Ship^   Bearing  From    ZZ. 

The    system    will    check   the   input    against   the   authorized    rang* 
(000-359) ,      and    should     the    input   not    be      within    this   ranee, 
then    the   following    warning    will   be    presented. 

PLEASE    ENTER   AS    THREE    DIGITS  (000-359)  f       WITHOUT    COMMAS    OR 

IECIMAL    POINTS 

***    PRESS    RETURN    TO    CONTINUE    *** 

When  ycu  continue,  you  will  again  be  presented  with  the 
guery  showr.  in  Figure  3.  55,  and  you  can  reenter  your 
response . 

You  will  next  be  asked  tc  indicate  the 
ship's  range  from  "ZZ. "  This  range  input  should  be  in 
yards,  and  entered  without  any  commas  or  decimal  points. 
The    guery    is  shown    in   Figure    3.56. 


As   an   example,       PAUL  E   FOSTER      is    50,000    yards    (25    nm)       from 

"ZZ.  "  The  correct  response      to   this      query      wculd    be      as 

follows. 

KB      —  50000    <cr> 

VR      —  ""Five"   "Zero"    "Thousand" 

Should   an      error  occur      in    making      this   entry,        the   warning 

shown    in    Eigure    3.57  wculd    be    presented. 
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FOR    PAUL    F    FOSTER 

???    WHAT    IS    TEE    SHIP'S    RANGE    FROM    ZZ    ???  (IN    YARDS) 

(ENTER    AS   SIX    DIGIIS    WITHOUT    COMMAS    OR    DECIMAL    POINTS 
E.G.    10,000=10000  RANGE    LIMITS    0    TO    600f000    YARDS) 


Figure   3.56        Query  -  Range   From   ZZ. 


PLJASI    ENTER    THE    RANGE    AS    SIX    DIGITS    WITHOUT    COMMAS    OR 
EECIKAL    POINTS. 

(E.G.    5,000=5000,    500,000=500000,    ETC.) 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure    3.57        ERROR   -   Range   Input. 

When  you  continue,  the  query  for  range 
(Figure  2.56)  will  again  b€  presented,  and  you  can  reenter 
your      response.  The      system    will      also      check,    your      input 

against  the  range  limits  (0  to  600,000  yards)  .  Should  your 
input  net  be  within  these  limits  (for  example  700000  was 
input),  then  the  warning  shown  in  Figure  3.58  will  be 
presented.  As   with      ether   error      corrections,      when      you 

continue,  the  original  query  will  be  presented,  and  you  can 
reenter    ycur  response. 

Once  the  bearing  and  range  have  been 
correctly  input,  the  values  are  presented  to  you  fcr  confir- 
mation. The  format  for  this  confirmation  is  shown  in 
Figure    3.59,  and   requires   a  YES/NO   response. 
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YOD    HAVE    ENTERED    "7C0000    AS    THE    RANGE    AS    THIS    UNIT'S 
RANGE,    AND    THIS    IS    NOT    WITHIN    THE    RANGE    LIMITS. 


Figure   3.58        ERRCB   -  Range   Outside   Prescribed   Limits. 


PAUL    F    FOSTER    IS     EEARING       90    DEGREES    TRUE    AND    RANGE 
5000C    YAEDS    FROM    ZZ. 

???     IS    THIS    CORRECT    ???  (YES/NO) 


Figure   3.59        Query  -    Bearing/Range   Confirmation. 

The  following  is  the  correct  response  to  this  guery  as 
applicable. 

KE      —  YES      <cr>  or  NO         <cr> 

VR      —   "Affirmative"  or        "Negative" 

Should  a  mistake  occur  in  making  this  response  you  will  see 
the    following: 

PLEASE    ENTER    "YES"    OR    "NO" 

Simply   reenter    your    YES/NO    response.  If   you  enter    "YES," 

then  ycu  will  either  sequence  to  the  next  ship  requiring 
position  input,  or  if  no  more  ships  r3qu±re  positions,  you 
will  move  to  the  next  section  of  -he  EUILD  module,  estab- 
lishing the  Composite  Warfare  Commander  (CWC)  Organization. 
If  ycu  had  entered  NC  to  the  position  confirmation  query, 
then  the  query  shewn  in  Figure  3.55  would  again  be 
presented,  and  you  would  repeat  the  position  entry  sequence 
for    that   ship. 
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(U )      Cme  rj     Seq  uence     zz        Cartesian      Co or  din 
System.  In  response      to      the      query   shown      in 

Figure  3.53,  if  you  desire  tc  input  the  positions  of  the 
tattle  group  units  in  cartesian  coordinates,  then  ycu  would 
enter   the   following. 

KB      —  CARTESIAN  <cr> 

VR      —      "Cartesian    Coordinate   System" 

You  would  then  fce  queried  for  the  cartesian  positions  of 
each  ship  in  the  battle  group  (less  the  unit  at  "ZZ")»  The 
format  fcr  the  specification  of  the  position  is  Quadrant, 
X-Cocrdinate,         Y-Cocrdinat e.  Each      of      these    entries     is 

seperated   by  a    space,      as   shown   in   the   query   example.  The 

composition   of   the   query   is    shewn   in   Figure   3.60. 


FOR    PAUL    F    FOSTER 

i 

???    WHAT    IS    HER    POSITION    IN    CARTESIAN    COORDINATES    ??? 

(ENTEB    AS    QUADRANT     (R,W,B,G),     SPACE,     X-POSITION, 
SPACE,    Y-POSITION) 

(E.G.     fi    C30    090) 

i 

Figure    3.60        Query   -   Cartesian    Position. 


To  demonstrate  the  correct  format  for  the  cartesian  position 
input,  let's  give  P5uL  F  FCSTER  the  position  WHITE  15C  1G0. 
Particularly  when  entering  your  response  from  the  keyboard, 
it  is  iupcrtant  to  conform  exactly  to  the  format  for  the 
response.  There    can   be  NO   extra   spaces.         When    making   the 

input  by  vcice,  while  the  input  command  has  some  length, 
this    is   not    a   problem   when    ycu    follow   x.he   example. 

KB      —  W    150    100         <cr> 

118 


VR      —      "Whits"   "One"    "Five"    "Zero"    "Space"    "One"    "Zero" 

"Zero"   "Carriage   Return" 

One    cf   the    first   things   that      the   system   checks   in   the    input 
is   that      the  quadrant    is   one      cf   the    four   options.  If   the 

quadrant   response   is   ether    that    E,         W,      B,      or    G,      then  the 
warning      shewn    in      Ficure      3-61      will   be      presented.  For 

example,    let's    say    ycu   accidentally   entered   " K"    as   the    quad- 
rant . 


~l 


YOD    HAVE    ENTERED    "K"    AS    THE    QUADRANT,     WHICH    IS    NOT    R, 
H,    B,    OR    G 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure    3.61        ERROB  -   Cartesian   Quadrant. 


When    ycu   continue,       ycu    will      be   presented   with   the    instruc- 
tion   shefcn    in   Figure    3.62. 


—] 


PIEASE    REENTER    THE    POSITION:       QUADRANT     (R,H,B,G), 
SPACE,    X-POSITION,    SPACE,    Y-FOSITION 

(E.G.       R    300    200) 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure   3.62        EBBOB  -    Cartesian   Position  Entry. 


It    ma j    seem   like   overkill,       but    when    you   continue,      you   will 
agair      be    presented      with  the      query   shown      in   Figure      3.60. 
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You  can  then  reenter  jour  cartesian  position  for  the  urit  in 
question.  Cnce  the  position  has  been  entered  correctly,  the 
system  will  present  the  quadrant  and  X/Y  positions  back  to 
you    fcr      confirmation.  This      display   is      shown    in      Figure 

3.63. 


'~1 


THE    CARTESIAN    POSITION    OF    PAUL    F    FOSTER    IS:    W     150    100 
???    IS    THIS    CORRECT    ???  (YES/NO) 


Figure    3.63        Query   -  Confirmation  of  Cartesian   Positicn. 


The    correct   response      to  this    query    would    be      "YES,"    as   this 
is      the   correct      position   for      FOSTER.  In   general,        the 

correct   response  to    this  query    would      be   as   shown    below,      as 
applicable . 


KE 

— 

YF.S        <cr> 

or 

NO      <cr> 

*E 

— 

"Affirmative" 

or 

"Negative" 

If  you  enter  YES  to  the  query  shown  in  Figure  3.63,  then  you 
will  te  asked  for  the  positicn  of  the  next  ship  in  the 
tattle  group,  or  if  all  ships  have  been  assigned  positions, 
then  ycu  will  mcve  tc  the  next  phase  of  the  BOILD  module, 
establishing  the  Composite  Warfare  commander  (CWC) 
Crganizaticn. 

f.      Establishing     the      Composite      Warfare      Commander 
(CWC)    Orgsnization 

The    next    phase    in   the    initialization    of    a    battle 
group    database    is  the   establishment   of    the   CWC   organization. 
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The    information      shown   in  Figure      3.64    will   be      presented   to 
you   as   an   intord  ucticn. 


YOU    WILL    NOW    ASSIGN    NAMES    AND    EMBARKED    UNITS    FOR    EACH 
WARFARE    COMMANDER.  NAMES    CAN    BE    ENTERED    TO    A    MAXIMUM 

OE    25    CHARACTERS.  SOME    EXAMPLES    ARE    AS    FOLLOWS: 

CCMCARGRU    1 
COMDESRON    9 
CCMDES  FCN    23 
CO,    PAUL    E    FOSTER 
CO,    MERRILL 

YCU    CAN    INCLUDE    TEE    COMMAS,    HOWEVER    BE    CAREFUL    IF    YOU 
ARE    ENTERING    EY    VCICE    TO    FOLLOW    THE    USER'S    MANUAL    NAME. 
IF    TEE    NAME    IS    NOT    IN    THE    USER'S    MANUAL,    THEN    MANUAL 
NAKE    ENTRY    WILL    EE    REQUIRED. 


Figure   3.6U        Introduction    to  CWC  Organization  Determination 


Within  this  section  cf  the  BUILD  module,  ycu 
will  identify  the  or canizat icns  which  will  function  as  each 
cf  the  warfare  commanders/coordinators,  and  identify  on 
which    ships   they   are    emtarlced.  Table   II    gives    examples   of 

the  tyjes  cf  organizations  which  could  function  as  a  warfare 
commander  cr  coordinator.  The  table  additionally  shows  the 
acceptable   entries    fcr  those   organizations. 

The  full  sccpe  of  the  sequence  establishing  the  CWC  organi- 
zation is,  determination  of  the  organization  functioning  as 
the  warfare  commander/coordinator,  determination  of  the  unit 
on  which  the  organization  is  embarked,  and  finally  a  display 
cf   the   full     CWC   Organization    for   your      confirmation.  For 

the  first  two  segments  of  the  seguence,  ycu  will  be  queried 
for   assignment   of   each      warfare   commander/coordinator   in   the 
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TABLE    II 
Keyboard/Vcice  Entries   for  Organizations 

KEYBOARD   ENTRY  VOICE    ENTRY 

CCMCABGEU  "Carrier   Group" 

CCMCEUDESGRU  "Cruiser    Destroyer    Group" 

CCMEESRCN  "Destroyer    Squadron" 

CCMSCBECN  "Submarine    Squadron" 

CO,    <snip  name>  "Commanding  Officer"      "<ship    name>" 


crder    presented      in    Table  III.  As   the   queries      are    iden- 

tical,     in    each      case,      only   cne    example       (assignment   of   the 
Anti-Air    Warfare   Commander)     will    be   discussed. 


TAELE    III 
CWC    Organization   Components 


OFFICER    IN    TACTICAL    COMMAND     (OTC/AB) 
ANTI-AIR    WJJEFARE    COMMANDER     (AAWC) 
ANTI-SUBMARINE    WARFARE    COMMANDER     (ASWC) 
ANTI-SURFACE    WARFARE    COMMANDER     (ASUWC) 
AIR    ELEMENT    COORDINATOR     (AREC) 
LAMPS     ELEMEKT    COOEDINATOR     (LEC) 
SUBMARINE    1IEMENT    COORDINATOR     (SEC) 
ELECTRONIC    WARFARE    CCCEDINATOR     ( EWC) 


O)  Assignment  of  an  Organization.  The  query 
shown  in  Figure  3.65  is  representative  of  those  applying  tc 
all        warfare        commanders/ coordinators.  The        specific 

commander/ccordinator   will    be   identified    within    the    query. 
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Figure  3-65    Query  -  Anti-Air  Warfare  Commander. 

!Ihe  desired  response  is  one  of  the  organizations  shewn  in 
Table  II  followed  by  the  appropriate  number  or  ship  name,  as 
applicable.  For  the  purposes  of  our  example,  we  will 
assign  Ccmmander  Cruiser  Destroyer  Group  Three  (CCMCRUDESGRU 
3)  as  AAWC.   This  is  shown  in  the  following  example. 

KB   --  COMCRUDESGRU  3     <cr> 

VR   —   "Cruiser  Destroyer  Group"  "Three"  "Carriage  Return" 

From  the  keyboard,  or  voice,  the  name  of  the  organization  is 

limited  to  twenty-five  (25)    characters.  Should  an  error 

occur  in  making  this  entry,  the  following  warning  will  be 
presented. 

ELEASE  REENTER  THE  NAME  CE  THE  ORGANIZATION 

This  would  be  followed  by  the  warfare  commander  guary  to 
which  ycu  are  responding.  Simply  reenter  your  response. 
Once  the  organization  has  been  correctly  identified,  there 
are  several  seguence  options  which  may  take  place. 

If  this  is  the  first  time  ycu  have 
assigned  the  specified  organization  to  a  warfare  commander/ 
coordinator  role,  ycu  will  next  be  queried  for  identifica- 
tion of  the  battle  grcup  unit  on  which  the 
commander/coordinator  is  embarked.  This  is  covered  in  the 
next  section. 

If  the  organization  has  been  identified 
earlier  as  functioning  as  another  commander/coordinator,  and 
the  unit   on  which  it  is   embarked  has  been   specified,   you 
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sill  skip  the  query  addressing  the  embarked  unit,  and  will 
sequence  tc  the  query  for  the  next  warfare  commander/ 
coordinator.  The    reason    for   this      is   that   the    system   will 

save  ycu  tine  by  assigning  the  organization  on  which  ycu  are 
working  tc  the  unit  you  have  previously  identified  as 
embarking   it.  In    essence,      you      will   skip   the    embarcation 

query    for   any  subsequent   entry    of   the    same    organization. 

The  final  variation  in  which  you  can  find 
yourself  is  initiated  by  naming  a  ship's  Commanding  Officer 
as  a  commander /coordinator.  It  would  be  redundant  tc  query 
you  about  on  which  ship  the  Commanding  Officer  of  CALIFORNIA 
is   emtarked.  If   ycu   name    a      ship's  CO   as   the   organization 

for  a  queried  commander/coordinator,  then  the  system  will 
automatically   emtark   the  CO    en      the   appropriate    ship.  Ycu 

would  net  be  queried  for  an  embarked  unit,  and  would 
sequence  tc  the  query  for  identification  of  the  next  warfare 
commander/ccor dinat or. 

(2)  Identification  of  the  Embarked  Unit.  Once 
the  organization  has  been  identified,  you  will  next  be 
queried  en  which  unit  the  commander/coordinator  is  emtarksd. 
This,  of  course,  is  subject  to  the  variations  mentioned 
above  regarding  the  type  of  organization  entry  you  make. 
The  composition  of  the  query  for  embarked  unit  is  shown  in 
Figure    3.66.  We    will     continue    with      the    development      of 

assigning    CCMCRUDESGRU    3   as    AAwC. 

Uniform  throughout  the  system,  whenever  a  requirement  for 
identification  of  a  ship  is  levied,  a  listing  of  the  avail- 
able units  is  shown.  Remember  that  the  system  will  confirm 
your  entry  by  atttempting  to  match  it  to  one  of  the  ships 
shown    in      the   listing.  For      our   example,      we      will   embark 

COMCRLDESGRU  3  onboard  CALIFORNIA.  This  entry  would  he  as 
follows. 

KB      —      CALIFORNIA    <cr> 
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FCB    CCMCRUDESGRU    3 

???    ON    WHICH    SHIP    IS    HE    EMfiARKED    ??? 

CARL    VINSON  PAUL    F    FOSTER  CALIFORNIA 


Figure   3.66        Query  -   Embarked   Unit. 

VR      --  "CALIFORNIA" 

Should  an  error  occyr  in  making  this  entry,  the  following 
warning    would   be   presented. 

PLEASE  ENSURE  THAT  YOUR  ENTRY  EXACTLY  MATCHES  ONE  CF  THE 
SHIPS    LISTED. 

Sou  will  again  be  presented  with  the  query  shewn  in  Figure 
3.66,      and    can      reenter   your    response.  Once      the    embarked 

unit  has  been  correctly  identified,  you  will  sequence  tc  the 
next  warfare  commander/coordinator,  for  identification  of 
the    organization   functioning   in   that      capacity.  If    all   of 

the  commanders/coordinators  have  been  identified,  then  the 
entire  CWC  Organization  will  be  presented  for  confirmation. 
This    is   covered    in    the   next    section. 

(3)  Confirmation  of  the  CWC  Organization.  The 
information  shown  in  Figure  3.67  reflects  a  respresent ative 
CWC  organization  that  you  may  have  entered.  It  is  presented 
to  allow  ycu  to  make  any  corrections  prior  tc  moving  en  tc 
the   next    phase    of   the  BUILD    module. 

When  ycu  continue,  ty  entering  "RETURN,"  you  would  see  the 
query  shewn  in  Figure  3.68,  asking  if  these  assignments  are 
correct. 
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HERE  IS  THE  COMPOSITE  WARFARE  COMMANDER  ORGANIZATION 
YCD  HAVE  ENTERED. 


CWC  CDR 

ORGANIZATION 

EMBARKED  IN 

OTC 

CCMCARGRU  1 

CARL  VINSON 

AAWC 

CCMCRUDESGFU  3 

CALIFORNIA 

ASWC 

CCMDESRON  23 

CARL  VINSCN 

ASUWC 

CC,  PAUL  F  FOSTER 

PAUL  F  FOSTER 

AEW 

CO,  CARL  VINSON 

CARL  VINSCN 

LEC 

CC,  PAUL  F  FOSTER 

PAUL  F  FOSTER 

SIC 

CCMSUBRON  4 

CARL  VINSCN 

ESC 

CCMCRUDESGFU  3 

CALIFORNIA 

***  PRESS  RETURN  TC  CONTINUE  *** 


Figure  3.67    Composite  Warfare  Commander  Organization. 


(YES/NO) 


???  ARE  THESE  ASSIGNMENTS  CORRECT  ??? 


Figure  3,68    Query  --  CIC  Organization  Correct. 

The  response  to  this  query  is  YES/NO  as  appropriate.  If 
the  information  is  correct,  and  ycu  enisr  YES,  then  you  will 
neve  en  to  the  next  phase  of  the  EUILD  module  in  initializa- 
tion of  the  battle  croup  database,  helicopter  embarcaticn 
status.  If  some  of  the  information  shown  in  Figure  3.67  is 
incorrect,  and  you  enter  NO,  then  the  view  shown  in  Figure 
3.69  «ill  bs  presented. 

You  identify  the  entry  which  is  incorrect  by  specifying  the 
acronym  CTC ,  AAWC,  ASWC,  etc.  Should  an  error  occur  in 
identifying  the  acronym,  the  following  will  be  presented. 

PLEASE  ENTER  THE  NAME  OF  THE  ACRONYM  EXACTLY  AS  INDICATED 
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???     WHICH    WARFARE    CCMMANEER(S)     IS/ARE    INCORRECT    ??? 


OTC  AAWC  ASWC 

IEC         ASUWC       ABEC 

(ENTER    TEE    APELICAELE    ACBCHYH) 


SEC 

EWC 


Figure  3.69   CWC  Organization  Incorrect. 

You  will  then  see  the  query  for  identification  of  the 
warfare  ccmaander  which  is  incorrect  (Figure  3.69).  Once 
the  commander/ coordinator  has  teen  identified,  you  will  b& 
asked  to  specify  which  element.,  organization,  embarked  unit, 
cr  both,  resuires  correction.  This  query  is  shewn  in 
Figure  3.70. 


???  WHICH  ENTRY  IS  INCORRECT:   ORGANIZATION 

EMBARKED  UNIT 
BOTH 

(ENTER  THE  APPLICAELE  PARAMETER) 


Figure  3.70    Query  -  Incorrect  Eleaent  Identification. 


If,  fcr  example,  when  we  initially  identified  the  organiza- 
tion functioning  as  AAWC,  we  had  input  "CONRDDESGRO  3,"  and 
we  new  wanted  to  correct  it,  we  would  enter  the  following  in 
response  to  the  query  in  Figure  3.70. 

KE   --      ORGANIZATION    <cr> 

VR   --  "Organization" 
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Fcllcwing  this  input,  you  would  be  presented  with  the  query 
shown  in  the  figure  representative  of  the  commander/ 
coordinator  with  which  you  are  working.  The  full  CWC  orga- 
nization, as  shown  in  Figure  3.67f  will  always  be  shewn  for 
conf irmaticn  prior  tc  allowing  ycu  to  move  to  the  next  phase 
cf  the  B0T1E  module.  The  full  range  of  options  for  identi- 
fication of  the  incorrect  element  is  shown  in  the  following 
example . 

KB       —      ORGANIZATION      <cr>         cr         EMBARKED   UNIT       <cr>         cr 

BOTH      <cr> 
VR      —      "Organization"  or  "Embarked  Unit"  cr 

"Beth" 

Should  there  be  a  mistake  in  making  this  response,  then  the 
following  will  be  presented. 

PLEASE  ENTER  "ORGANIZATION,"   "EMBARKED  UNIT,"  OR  "EOTH. " 

This  will  he  followed  by  the  query  shewn  in  Figure  3.70  , 
after  which  you  can  reenter  your  response. 

g.   Determination  of  Helicopter  Embarcation  Status 

The  next  and  final  phase  of  initializing  the 
battle  group  database  is  determination  of  the  helicopter 
embarcation  status  fcr  those  ships  which  are  HELO  capable. 
If  ycu  had  to  manually  enter  the  capabilities  for  a  ship  not 
in  the  iraster  database,  then  ycu  are  familiar  with  this 
input  sequence,  as  ycu  specified  whether  the  unit  was  HELO 
capatle  as  well  as  whether  the  detachment  was  embarked. 
Fcr  those  units  whose  capabilities  were  automatically  input, 
you  will  be  initially  establishing  the  EMBARKED/NOT  EMEARKED 
capability.  For  these  ships  for  which  this  entry  had  been 
jrade  manually,  you  will  be  reaffirming  the  currency  of  the 
embarcation  status.  The  composition  for  the  queries  is 
keyed  tc   the  type   cf  HELO   capability  that   the  ship   has. 
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Aircraft  carriers  always  have  their  detachments  embarked  in 
the  master  database,  therefore,  ycu  will  not  be  queried  as 
to  their  embarcation  status.  (You  will,  however,  te  able  to 
change  that  embarcaticn  status  in  the  STATUS  module,  if  you 
so  desire.)  Using  EAUL  F  FOSTER  as  an  example,  the  query 
is  shewn  in  Figure  3.71. 


???  DCES  PAUL  f  FOSTER  HAVE  HER  LAMPS  DETACHMENT 
ONBOARD  ??? 


Figure  3.71    CUEHY  -  HELO  Embarcation  Status. 


The  desired  response   to  this  query  is  "YES"  or  "NO."    The 
format  fcr  the  correct  respense  is  as  follows. 


KE   —      Y5S     <cr>     or 
VR   —    "Affirmative"    or 


NO    <cr> 

"Negative" 


This  query/response  sequence  will  continue  for  each  ship 
that  has  a  HELO  capability.  Should  there  be  an  errcr  in 
naking  this  response,  then  you  will  be  advised  to  "ENTER  YES 
CR  NC,"  after  which  ycu  can  reenter  ycur  response.  Once  the 
heliccpter  embarcaticr  status  has  been  determined  fcr  all 
HELO  capable  ships,  ycu  are  finished  with  initially  forming 
the  battle  group  datatase. 

2  •   Completion  of  Battle  Gro u£  Database  Initialization 

After  the  helicopter  embarcaticn  status  had  been  determined, 
you  are  finished  with  initializing  the  battle  group  data- 
base. As  was  mentioned  several  paragraphs  earlier,  the 
system  will  now  conduct  an  automatic  SAVE  of  the  information 
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you  have  entered.  Remember,  though,  that  this  inf crmation 
will  be  erased  if  jcu  terminate  your  session  with  a  STOP 
command.  When  you  next  invoke  the  BUILD  module  from  the 
query  shewn  in  Figure  3.6,  ycu  will  have  the  capability  to 
INSERT  or  DELETE  a  unit,  or  REBUILD  zhe  entire  battle  group 
database.  The  inf or nation  shewn  in  Figure  3.72  (adjusted) 
represents  the  optiens  that  are  now  available  to  you  upon 
invoking  the  BUILD  mcdule.    These  capabilities  will  covered 


*  BUILE  MODULE  OPTIONS  * 


INSERT    INSEET  A  UNIT  INTO  THE  EATTLE  GROUP 

DATAEASE 


DEIETE         DELETE    A    UNIT    EROM    THE    3ATTLE    GROUP  | 

DATAEASE  I 

I 

REECI1D   DELETES  ALL  THE  INFORMATION  CURRENTLY       | 

IN  USE  FOR  THE  BATTLE  GROUP  AND  ALLOWS  | 
YOU  TC  REBUILD  THE  ENTIRE  GROUP.  I 

I 

???    WHAT    IS    YOUR    CHOICE     (INSERT,     DELETE,    REBUILD)     ??? 


Figure    3.72        BUILD    Module   Options. 

in   the    fcllcw-on  sections  of   BUILD   module   operations. 

3 .      INSERT    a   Un i t   Into    the    Battle    Gr ou£   Database 

If  you  desire  to  INSERT  a  unit  into  the  battle  group 
database,  ycur  response  to  -he  query  shown  in  Figure  3.72 
would    be    as    follows. 

KB   —      INSERT     <cr> 
VR   —    "Insert  a  Unit" 

The  fiist  presentation   will  be  a  query  for  the   name  of  the 
ship  ycu  desire  to  INSERT.     This   will  be  indicated  by  the 
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appearance  cf  the  "SHIP  NAME  ?"  prompt  with  which  ycu  are 
familiar.  Following  the  prcmpt,  you  should  enter  the  name 
cf  the  ship  in  questicn.  The  restrictions  on  the  format  of 
the    name   are  the  same  as   we    have   discussed    before.  If   you 

need  Here  information  en  name  formats,  refer  to  the  section 
in   BDILD   module    operations    covering      ship    name  entry.  For 

cur  example  battle  gicup,  shculd  we  desire  to  add  OSS  KANSAS 
CITY    (AOF-3)  ,   the   following    input   would   be    appropriate. 

KB      —  KANSAS    CITY  <cr> 

VR      —  "KANSAS    CITY" 

Shculd  there  be  an  error  in  making  this  response,  you  will 
be  asked  tc  reenter  the  name  of  the  ship  you  desire  to 
INSERT.  Once  the  name  has  been  correctly  input,  the  system 
will    recenfirm    with    ycu   the      spelling   of    your  entry.  This 

reccnf irnation    is   shewn    in    Figure    3.73. 


Figure    3,73        Confirmation   of  INSERTed   Ship,s    Name. 


Had  we  accidentally  mispelled  KANSAS  CITY,  then  the 
irispelled    name    wculd      have    appeared    in   the      query.  If   the 

name  is  correctly  spelled,  and  you  answered  "YES"  xc  the 
query,  the  master  database  will  be  searched  for  the  ship 
whose    name    you    have    entered.  If    located,      its    capability 

database    will   be   automatically   filed.  If   it    is    net    found 

in  the  master  database,  then  manual  entry  of  her  capabili- 
ties will  te  required.  Manual  entry  is  discussed  under 
Initializing  the   battle    group      database.  If   your   response 
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to  the  confirmation  query  had  been  NO,  then  the  "SHIP  NAME 
?"  prompt  would  again  appear  and  you  could  reenter  the  name 
of  the  ur.it  you  desire  to  INSERT. 

Cnce  the  ship's  capabilities  have  been  determined, 
either  automatically  or  manually,  you  will  next  be  asked  for 
the  ship's  position.  The  fcrmax  for  this  query  is  depen- 
dent upcn  what  coordinate  system  you  specified  when  you 
initially  fcrmed  the  tattle  group.  The  composition  of  the 
query  will  be  either  that  shown  in  Figure  3.55  or  Figure 
3.60.  If  you  require  more  detail  in  responding  to  these 
gueries,  refer  to  the  section  en  Polar  or  Cartesian  posi- 
tions discussed  earlier.  After  determination  of  the  ship's 
position,  ycu  will  be  asked  for  her  KELO  smbarcation  status, 
if  she  is  HELO  capable.  Once  the  embarcation  status  has 
teen  determined,  you  will  be  presented  with  the  new  composi- 
tion of  the  battle  qrcup.  Ihis  presentation  is  shewn  in 
Figure  3.74. 


HERE  ARE  TEE  UNITS  IN  YOUR  BATTLE  GROUP 

CARL  VINSON      PAUL  F  FOSTER      CALIFORNIA 
KANSAS  CITY 

***  2RESS  RETURN  TO  CONTINUE  *** 


figure  3.74    Sew  Battle  Group  Composition. 


When  ycu  continue,  ycu  will  be  advised  that  if  this  change 
to  the  tattle  group  composition  affects  the  CWC  organiza- 
tion, ycu  can  make  the  required  correction  in  the  STATUS 
module.  The  composition  of  this  warning  is  shown  in  Figure 
3.75.  When  you  continue,  ycu  will  be  returned  to  the  MAIN 
module. 
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NC1E  —  IF  THIS  CHANGE  AFFECTS  THE  CWC  ORGANIZATION, 
YCC  CAN  CHANGE  THE  ORGANIZATION  IN  THE  STATUS  MODULE. 

***  PRESS  RETUSN  TO  CONTINUE  *** 


Figure  3.75   Warning  -  Impact  of  Change  on  CWC  Organization. 

4.   DELETE  a  Unit  From  the  Battle  Group  Database 

If  you  desired  to  delate  a  unit  from  the  battle 
group  database,  you  would  make  the  following  entry  in 
response  to  the  guery  shown  in  Figure  3.72. 

KB   —         DELETE    <cr> 
VR   —      "Delete  a  Unit" 

The  first   presentation  you   will  see   is  a   listing  of   the 

battle  gioup  as  it   now  exists.  If   you  now   include  the 

insertion  of  the  KANSAS  CITY  into  the  battle  group,   as  was 

done  in  the  INSEET  example,    the  composition  of  the  listing 
is  shewn  in  Figure  3. "56. 


TEE  EATTLE  GROUP  CONSISTS  CE: 

CAEL  VINSON        PAUL  E  FOSTER       CALIFORNIA 
KANSAS  CITY 

???  WHICH  UNIT  DO  YOU  DESIRE  TO  DELETE  ??? 


Figure  3.76    DELETE  Cption  -  Current  Battle  Group  Listing. 


You  should   enter  the  name  cf   the  uniz  exactly  as   shewn  in 
the  listing.    Should  a  mechanical  error  (hitting  an 
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incorrect  execution  key)  occur  in  making  this  response,  you 
will    see   the  following: 

PHASE    ENTER    THE    NAME   OF    THE    UNIT    YOU    DESIRE    TO    DELETE 

After    this,      simply    reenter    the   name     of   the    unit.  If    you 

enter  the  name  of  a  unit  net  in  the  battle  group  database, 
then    the   following   warning    will   be   displayed. 

YOUR  ENTBY  CANNOT  EE  LOCATED  AMONG  THE  NAMES  OF  THE  EfiTTLE 
GROUP    UNITS.       PLEASE    CHECK    THE    SPELLING/FORMAT    AND    REENTER. 

***    PRESS    RETURN    TO    CONTINUE    *** 

When  ycu  continue,  the  query  shown  in  Figure  3.76  will  again 
be   presented,      and   ycu  can      reenter   your   response.  If    you 

desired  to  delete  the  unit  designated  as  "ZZ,"  you  will  be 
removing  the  reference  position  for  the  graphics  portions  of 
the   system.  If   the      "ZZ"    unit   is      deleted,      you      will   be 

advised  that  the  Battle  Group  position  information  must  be 
reinitialized.  This   procedure    starts    with   the    query    shewn 

in   Figure   3.51,    which  is    where   you   will    be   cycled. 

5  •      EEECILD    the    Battle    Grc uj:    Database 

If  you  desire  to  form  a  new  battle  group  during  a 
decision  support  system  session,  you  would  enter  the 
following   in  response   to   the   query   shown   in    Figure    3.72. 

K3      —  REEUILD         <cr> 

VR      —      "Rebuild  Option" 

When  ycu  select  the  BEBUILD  option,  you  have  indicated  that 
you  want  to  erase  the  current  battle  group  database,  and 
reconstruct   a   new      one.  To   ensure   that      you  recognize   the 

ramifications  of  making  this  selection,  the  warning  shown  in 
Figure   3.77    will   be    presented. 
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YOC  HAVE  OPTED  TO  ERASE  THE  BATTLE  GROUP  DATABASE 
ANE  RIEUILD  IT. 

???  ABE  YOU  SURE  THIS  IS  WHAT  YOU  WANT  TO  DO  ??? 

(YIS/NO) 


Figure   3,77        IARHIHG  -   Battle   Group   Database   To    Be    Erased. 

The    desired   response      to   this   query   is    YES   or      NO.  If   you 

enter   "YES,"     then    ycu   will      repeat   the     sequences  discussed 

under    Initializing   the   Battle   Grcup  Database.        If  ycu   enter 

NO    tc      this   query,      then      you   will      be   returned   to  the   MAIN 

module,        and  the      current      battle      group   database  will      be 

retained.        Should    an     error   occur   in    making     this  response, 
you    will   be    asked  tc   reenter   ycur   YES/NO    response. 

H.       STATES    MODULE    OPEBATIONS 

The  STATUS  module  basically  facilitates  data  manipula- 
tion within  the  battle  group  database.  In  this  nodule  you 
can  DISPLAY  various  capabilities  of  the  battle  grcup,  as 
well  as  DISPLAY  the  entire  database  for  a  particular  unit. 
It  would  be  in  this  ircdule,  also,  that  you  could  CHANGE  any 
element  cf  the  unit's  database,  CHANGE  force  unit  positions, 
cr  make  a  CHANGE  to  the  CW C  Organization.  Finally,  the 
STATUS  mcdule  allows  you  tc  enter  a  field  of  REMARKS  about 
any  unit,  and  have  these  remarks  made  a  part  of  that  unit's 
database.  Ihe  STATUS  module  is  invoked  from  the  query 
shown    in    Figure    3.6    as   shown    below. 

KB       —  STATUS      <cr> 

VR      —  "Status    Module" 
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The  first  time  ycu  invoke  this  module,  you  will  be  presented 
with  the  explanation  cf  module  capabilities  shown  in  Figure 
3.78  (adjusted)  . 


BATTLE  GROUP  ASSET  MANAGEMENT 
DECISION  SUEEORT  SYSTEM 

*  STATUS  MODULE  * 

THIS  MODULE  MILL  AIICW  YCU  TO  PERFORM  THREE  MAJOR 
FUKCTICNS.   FIRST,  YOU  CAN  "DISPLAY"  UNIT  DATABASE, 
FCBCE  INFORMATION  (HELO  CAPABILITIES,  TASS  CAPABILI- 
TIES, POSITIONS,  MISSIONS,  AS  WELL  AS  TOMAHAW K/H ARECCN 
CAPABILITIES.   SECCND,  YCU  CAN  CHANGE  DATA  FOR  A  PAR- 
TICULAR UNIT,  FORCE  POSITIONS,  OR  AN  ELEMENT  OF  THE 
C*C  CEGANIZATION.   FINALLY,  YOU  CAN  ADD  REMARKS  (UP  TO 
25  CHARACTERS)  FOR  ANY  UNIT. 

***  PRESS  RETURN  TC  CONTINUE  *** 


Figure  3.78    STATUS  Module  Capabilities. 

Ihis  module  does  not  utilize  any  computer  graphics  capa- 
bilities, therefore,  all  displays  will  ba  made  en  ycur 
terminal  screen.  When  you  continue,  you  will  be  shown  the 
module  cptions,  and  asked  if  you  desire  to  review  the 
command  format  for  any  option.  This  view  is  shows  in 
Eigure  3.79. 

Each  cf  these  options,  with  their  respective  commands,  will 
te  discussed  in  succeeding  portions  of  this  section  cf  the 
manual.  If,  in  respense  to  the  query  shown  in  Figure  2.79, 
you  dc  net  desire  to  review  the  specific  command  for  a  capa- 
bility ycu  wish  to  utilize,  ycu  would  enter  CARRIAGE  RETURN, 
as  shewn  in  Figure  3.80.  This  input  will  generate  the 
query  shewn  in  Figure  3.81,  asking  you  to  input  your  desired 
module  cemmand.     Shculd  an  error  occur  in  making  this,  or 
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STATUS  MODULE  OPTIONS 

DISPLAY  CHANGE  REMARKS 

IF    YCU    WOULD    LIKE    10    REVIEW    THE    FORMATS    FOR    THE    STATUS 
MODULE    COMMANDS,    ESTER   THE    AFPROPRITATE    OPTION     (DIS- 
PLAY,   CHANGE,    REMARKS),     OR    "EXIT"    IF    YOU    WANT    TO    LEAVE 
THE    MCDULS,     OTHERWISE    PRESS    THE    CARRIAGE    RETURN    TO 
CONTINUE. 


Figure    3.79        STATUS    Module    Options. 

any  response  to  the  query  shewn  in  Figure  3.79,  then  the 
follcwinc    warning   will   be   presented. 

PLEASE    ENTER    YOUR    SEIECTION    EXACTLY    AS    PER    THE    INSTRUCTIONS 

***    PRESS    BETURN    TO    CONTINUE    *** 

fihen  ycu  enter  "EETUB^"  as  shown  in  Figure  3.80,  you  will 
again  te  presented  with  the  view  shown  in  Figure  3.79,  and 
can    reenter    your  response. 


Make   the    follcwinc   entries,    as   appropriate,    to    effec 
a    "CARRIAGE    RETURN"    or   a    "RETURN*    command. 

K3   —         <cr> 

VR   —   "Carriage  Return" 


Figure  3.80    Entry  of  "CABHIAGE  RETURN"  or  "RETURN". 


Seme   discussion  about   how  the   module   operates  is  in 
crder  ax  this  point.    The  system  will  look  at  your  commands 


137 


Figure  3.81    STATUS  Module  Command  Query. 


and  break  the m  up  into  two  or  three  segments  depending  on 
the  first  word  of  the  command.  The  key  positions  for  the 
break  up  are  the  spaces  between  the  words  of  the  command. 
When  entering  from  the  keyboard,  be  sure  that  if  the  example 
shows  a  space,  you  enter  the  space.  Otherwise,  the  system 
will  not  recognize  ycur  command  segments.  The  examples  for 
entry  by  voice  already  allow  for  the  "space"  requirement  in 
most  cases.  When  they  don't,  the  examples  will  show 
"Space"  in  the  VR  command  string.  Before  we  discuss  the 
functions  of  each  mcdule  option,  it  would  be  prudent  to 
review  seme  of  the  pitfalls  you  may  encounter  in  entering 
the  required  commands. 
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Kcdule    Command    Format    Errors 


As  we  have  already  discussed,  this  module  looks  at 
all  commands  in  terns  of  a  specific  number  of  segments. 
The  command  you  will  enter  will  be  broken  down  into  segments 
with    the   spaces      serving  as    the   break      points.  The    system 

will  then  look  at  each  segment  individually,  and  in  a  tree 
like    fashion,      evaluate   succeeding   segments.  For    example, 

there  are  three  possible  entries  which  could  comprise  the 
first    segment,      DISPIAY,      CHANGE,        or    REMARKS.  Once   this 

segment  has  been  evaluated,  the  second  segment  is  identi- 
fied. If  the  DISPIAY  option  were  selected,  and  identified 
as  the  first  command  segment,  then  the  system  would  lock  for 
UNIT,  FCECE,  or  COftCAND,  as  the  second  segment,  as  these 
three    entries   are  the  ONLY    enss   which   could   legally    follow   a 
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EISPLAY   option    command.  This      process    would  continue   into 

evaluation  of  the  third  segment,  if  the  particular  command 
entry  required  one.  For  your  purposes,  you  need  only  think 
of  the  nodule  option  commands  as  complete  phrases  in  a 
required  format.  Tc  avoid  any  confusion,  the  next  sections 
will  discuss  the  warnings  which  will  be  system  generated  in 
response  to  an  inability  tc  recognize  a  particular  segment 
cf   a    command.  These   section      are   here,      not   to   imtimidate 

you,  rut  rather  to  give  you  some  reference  to  the  specific 
cause    cf   an   error. 

a.      Error  --    First    Command   Segment 

Once  you  have  entered  your  module  option 
command,  the  systeir  will  lock  for  the  first  segment  (or 
word).  As   you      have   seen,      there    are      only   three    possible 

choices  for  this  segment,  as  far  as  the  system  is  concerned, 
DISPLAY,      CHANGS,      or    REMARKS.  If    the    system    cannot    match 

the  first  segment  of  your  command  to  one  of  these  words, 
then    the   information    shown    in    Figure    3.82    will  be    presented. 


YCDR    CCHflAND    CANNCT    BE    ASSOCIATED    WITH    "DISPLAY", 
"CHANGE",    OR     "REM5RKS".        YOU    WILL    3E    ASKED    TO    REENTER 
THE    CCMHAND. 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure   3.82        ERROR   -   First   Segment. 


You   would   ccntinue      ty   entering   "CARRIAGE   RETURN,"      as    shewn 
in      Figure    3.80.  Following      this      entry,      you      would     be 

returned    tc    the      view   shown    in    Figure    3.79,         and   resume   the 
query/response    sequence. 
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h.      Error   in    Second    Segment 

The  system  will  anticipate  the  possible  choices 
for  a  second  segment,  based  en  the  identity  of  the  first 
segment.  For    the    DISPLAY    option,    there   are,    again,      three 

possible    words    which   could    be   second   segments,   FORCE,      UNIT, 
cr  COMMAND.  If   one  of  these   three   words    cannot    be   matched 

to   the   second  segment  in   your   command,      the   warning   shewn   in 
Figure    3.83   will   be    presented. 


TEE    HEM    Y00    WISHED    DISPLAYED    IS    NOT     "UNIT",     "FORCE", 
OE    "CCMMAND".        YOU    WILL     HAVE    TO    REENTER    YOUR    COMMAND. 


***    PRESS    RETURN    TC    CONTINUE    *** 


Figure   3.83        ERBCB   —   DISPLAY   Option   Second   Segment. 


Ycu  wculd  continue  by  entering  CARRIAGE  RETURN,  shewn  in 
Figure  3.80,  and  you  would  be  returned  to  the  query  shewn  in 
Eigure  3.79  where  ycu  can  reinitiate  the  query/response 
sequence . 

If  the  first  segment  of  your  module  option 
command  were  CHANGE,  the  system  would  look  fcr  either  FCRCE, 
UNIT,      cr   CCMMAND  as   the   second   segment.  If  none   of   these 

words  cculd  be  matched  tc  the  second  segment  cf  your 
cemmand,  the  information  shown  in  Figure  3.8U  would  be 
displayed. 


You  wculd  continue  by  entering  "CARRIAGE  RETURN,"  as  shewn 
in  Figure  3.80,  and  jcu  would  be  returned  to  the  query  shewn 
in  Figure  3.79,  frcm  which  you  can  reinitiate  the  query/ 
response   sequence. 
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THE  EIEMENT  YCU  WISH  TO  CHANGE  IS  NOT  "FORCE".  "COM- 
MANE",  OF  "UNIT".  YOU  SflLI  HAVE  TO  REENTER  THE  COM- 
MAND. 

***  PRESS  RETUEN  TO  CONTINUE  *** 


Figure  3.8U    ERECB  —  CHASGE  Option  Second  Segment. 

If  the  first  segment  of  your  module  cption 
commard  were  REMARKS,  the  system  would  look  for  a  ship  name 
as  the  second  segment.  If  there  was  an  error  in  recog- 
nizing ycur  entry  as  the  name  of  a  ship  in  the  battle  group, 
you  would  be  simply  asked  tc  reenter  the  name  of  the  ship  in 
guesticn,  and  would  not  be  returned  to  -he  the  query  shewn 
in  Figure  3.79. 

c.   Error  in  Third  Command  Segment 

(1)  "DISPLAY  FORCE"  Command.  If  ycu  desired 
to  display  a  capability  of  the  force  (DISPLAY  FORCE) ,  then 
the  system  would  lock  for  one  of  the  following  words  to 
identify  the  capability  ycu  desire.  These  words  are, 
MISSICNS,  POSITIONS,  HELO,  HARPOON,  TASS,  and  TOMAHAWK.  If 
none  cf  these  words  can  be  matched  to  the  third  segment  of 
your  cemmand,  the  information  shown  in  Figure  3.85  will  be 
displayed. 

You  shculd   make  the   following  entry,    in  response   tc  the 
guery  shewn  in  Figure  3.85,  tc  review  the  cemmand  formats. 

KB  —      FORMAT     <cr> 
VR   —   "Eeview  Formats" 
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YOUR    COMMAND    HAS    KCT    BEEN    MATCHED    TO    THE    AVAILABLE    OP- 
TIONS.      YOU    WILL    HAVE   TO    REENTER    IT.       SHOULD    YOU    DE- 
SIRE   TO    REVIEW    THE    COMMAND    FORMAT,    ENTER    "FORMAT", 
OTHERWISE,    IF    NOT,    PRESS     CAERIAGE    RETURN. 


Figure    3.85        ERROR   —  Command   Incorrect. 

If  ycu  dc  net  desire  to  review  the  command  formats,  then  you 
should  ester  "CARRIAGE  RETURN,"  as  shown  in  Figure  3.80,  and 
the   guery   shown    in    Figure   3.81    will   be   displayed. 

(2)  "DISPLAY  UNIT"  Command.  If  ycu  desired  to 
display  the  database  for  a  unit  (DISPLAY  UNIT) ,  the  system 
will  anticipate  the  name  of  a  ship  in  the  battle  grcup  as 
the  third  segment.  It  your  entry  cannot  be  marched  tc  one 
cf  the  battle  group  units,  you  will  be  asked  to  reenter  the 
name    of   the   unit   in    guestion. 

(3)  "DISPLAY  COMMAND"  Command.  There  is  no 
third  word  in  the  command  to  display  the  CWC  Organization, 
therefore,    the    system  does    not   look,    for   one. 

(4)  "CHANGE  FORCE"  Command.  The  only  force 
element  which  can  be  changed  is  POSITIONS,  therefore,  the 
system  will  look  for  POSITIONS  as  the  third  word  in  This 
command.  If  the  third  word  of  your  command  cannot  be 
matched  to  POSITIONS,  the  information  displayed  in  Figure 
3.86    will   be  displayed. 

Tc  continue,  enter  "CARRIAGE  FETURN,"  as  shown  in  Figure 
3.80,  and  you  will  be  returned  to  the  guery  in  Figure  3.79, 
from    which    you   can    reinitiate   the   query/response    sequence. 
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YOD    CAN    CNLY    CHANGE    FORCE    FCSITIONS.       PLEASE    REENTER 
YCCR    COMMAND. 


***    PRESS    RETURN    TO    CONTINUE    *** 


Figure    3.86        ERROR    —  CHARGE    FORCE   Option    -   Third   Segment. 

(5)  "CHANGE  UNIT"  Command.  The  third  segment 
in  the  CHANGE  UNIT  ccmmand  is  the  name  of  the  unit  whcse 
database  you  desire  tc  change.  If  the  system  cannot  match 
the  naire  in  your  command  to  one  of  the  battle  group  units, 
as  you  have  seen  before,  ycu  will  be  asked  to  reenter  the 
rame    cf   the    unit  concerned. 

(6)  "CHANGE  COMMAND"  Command.  There  is  not 
third  segment  to  the  CHANGE  CCKMAND  command,  therefore,  the 
system    will   not    look    for   one. 

2.      STATUS    Module  zz  Display,    Option 

The    commands     required   to   initiate     the   DISPLAY      features   cf 
this    module   are    shown  in      Figure   3.87    (adjusted)  .  To   have 

this      view    presented,        you      wculd      enter   the      following     in 
respcrse   tc   the    query  shown    in    Figure    3.79. 

KB      —  DISPLAY  <cr> 

VR      —    "Display"    "Carriage   Return" 
Ycu    would   enter    "RETURN,"   as    shown    in    Figure    3.80   to 
continue.  When   ycu   continue,      you      will   be   asked    to    input 

the    mcdule      command    ycu     desire.  This      query   is      shown   in 

Figure    3.81.  The    fact      that    you      have    just      reviewed   the 

"DISPLAY"   ccmmands    dcss      NOT   restrict    ycu   to      just    "DISPLAY" 
commands.  At      this   point,       you      can    designate    any      of   the 
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"DISPLAY"  COMMANDS: 

DISPLAY   UNIT    (DMT  NAME)     DISPLAYS  UNIT  DATAEASE 

(ENTER  UNIT  NAME  WITHOUT  PAEENS 

E.G.  DISPLAY  UNIT  MERRILL) 

DISPLAY   FORCE   HE1C  DISPLAYS  HELO  CAPAELE 

UNITS 
MISSION  DISPLAYS  UNIT  MISSIONS 

POSITIONS       DISPLAYS  UNIT  POSITIONS 
HAEPOON  DISPLAYS  HARPOON 

CAPABLE  UNITS 
TCMAHAWK        DISPLAYS  TOMAHAWK 

CAPABLE  UNITS 
TASS  DISPLAYS  TASS  CAPAELE 

UNITS 


DISPLAY       COMMAND  DISPLAYS    CWC    ORGANI- 

ZATION 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure  3.87        STATUS    Hodule   —   DISPLAY   Commands. 

irodule    options.         We    will   next    look   at   each  of  the   "DISPLAY" 
features . 

a.      Displaying   a  Unit's   Database 

This    feature  of    the    STATUS    module    will   allow   you    to    view   the 
entire    datatase    for      the  unit   ycu   designate.  In    order   to 

display    the    unit's    database,      you      would   enter  the   following 
in   response   to    the    query  shown    in    Figure   3.81. 

KE  —  DISPLAY  UNIT  PAUL  F  FOSTER  <cr>  or 
DISELAY    UNIT    CARL    VINSON         <cr> 

IB  ~  "Display"  "Unit"  "PAUL  F  FOSTER"  or 
"Display"    "Unit"    "CARL    VINSON" 
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The  same  requirements  for  ship  names  apply  here  as  ycu  have 
seen  earlier.  You  could  use  the  shorter  name  forms  (e.g. 
FOSTER  for  PAUL  F  FCSTER  or  VINSON  for  CARL  VINSON)  in 
either  input  case.  The  system  will  segment  the  command  in 
the  following  order,  "DISPLAY,"  "UNIT,"  "<ship  name). "  As 
you  have  already  seen,  the  DSS  will  attempt  to  match  the 
name  of  the  unit  you  have  entered  with  those  in  the  battle 
group  database.  If  there  is  no  match  made,  you  will  be 
asked  to  reenter  the  rame  of  the  ship  ONLY,  not  the  entire 
ccmmacd.  The  format  for  the  database  display  is  shewn  in 
Table  IV.  In  the  display  for  an  actual  ship,  the  headings 
shown  in  Table  IV,  as  well  as  the  ship's  capabilities  would 
be  shewr  together.  PAUL  F  FOSTER  is  utilized  as  an 
example.  Some  comments  about  the  rationale  for  the  format 
cf  this  display  are  appropriate.  In  order  to  accomodate 
the  amount  cf  data  ir  the  ship's  database,  and  still  display 
it  or  one  view,  the  resultant  format  is  somewhat  congested. 
Incorporating  the  information  this  way,  however,  affords  the 
user  the  advantage  cf  having  everything  readily  displayed, 
as  opposed  to  sequencing  through  different  views.  The  data 
is  organized  into  categories  as  a  method  of  partitioning  the 
information  shown.  It  is  the  opinion  of  the  author  that 
once  familiar  with  the  information  format,  the  user  will 
feel  comfortable  with  the  display. 
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There  are  two  caveats  regarding  the  display  of  a 
unit  database.  First,  if  the  ship  to  be  displayed  is  an 
aircraft  carrier,  the  GROUP  COMMANDER  entry  will  be  replaced 
with  CARRIES  GROUP.  Second,  the  format  of  the  position 
information  is  keyed  to  the  type  of  coordinate  system  chosen 
(polar  or  cartesian).  Finally,  unless  you  enter  them, 
there  are  nc  stcred  REMARKS  fcr  a  ship.  Therefore,  the 
field  fcllcwing  that  heading  may  be  blank.  When  ycu  enter 
"CARRIAGE  EETURN,"  following  this  display,  you  will  be 
returned  to  the  query  shewn  in  Figure  3.79. 

t.   Display  Force  Helicopter  Capabilities 

This  feature  of  the  STATUS  module  will  allow  you 
to  observe  the  heliccpter  capable  units  in  the  battle  group 
and  determine  their  detachment  EHBAHK/NOT  EMBARKED  status. 
Sou  inveke  this  capability  by  entering  the  following  in 
response  to  the  query  shown  in  Figure  3.81. 

KB   —  DISPLAY  FORCE  HELO       <cr> 

VR   —  "Display"  "Battle  Group"  "Helicopter  Units" 

This  command  would  generate  a  display  on  the  terminal 
screer,  of  the  battle  grcup  units,  their  helicopter  capa- 
bility, and  the  emtarcaticn  starus  of  the  detachment,  if 
applicable.  Obviously,  if  the  ship  has  nc  capability,  the 
status  wculd  be  NOT  EMBARKED.  The  format  fcr  this  presen- 
tation, with  some  representative  data,  is  shown  in  Figure 
3.88. 

Within  the  composition  of  Figure  3.88,  you  will 
notice  the  capability/status  entry  "NO  STATUS."  This  means 
that  there  is  no  database  entry  for  these  capabilities. 
The  ncrmal  manner  in  which  this  could  occur  would  have  ccme 
from  manual  database  entry  in  the  BUILD  module.  When  you 
are  inputting  the  ship's  capability  database  manually,  you 
can  skip  seme  of  the  required  information  from  the 
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*  BATTLE  GBOUP  HELO  CAPABLE  UNITS  * 

CSI3  NAME  CAPABILITY  EMBARKED 

FADL  F  FCSTSR  LAMPS  DETACHMENT  EMBARKED 

CAIIFCBNIA  NOT  CAPAELE  NOT  EMEARKED 

CARL  VINSON  SH-3  DETACHMENT  EMBARKED 

KANSAS  CITY  CH-46  DETACHMENT  EMBARKED 

GUAM  NO  STATUS  NO  STATUS 

***  PRESS  RETUBN  TO  CONTINUE  *** 


Figure  3.88   STATUS  Hodule  —  Display  of  Helo  Capable  Units. 

capability  menus.  The  appearance  of  "NO  STATUS"  indicates 
that  this  has,  in  fact,  happened.  To  correct  this  situ- 
ation, ycu  would  utilize  the  CHANGE  capability  of  the  STATUS 
module  tc  input  the  appropriate  capability,  a  topic  which  is 
forthcoming.  When  ycu  are  through  with  reviewing  the  heli- 
copter capability  information  and  continue,  you  will  be 
returned  tc  the  presentation  shewn  in  Figure  3.79. 

c.   Display  cf  Force  Positions 

This  feature  cf  ths  STATUS  module  allows  ycu  to 
display,  on  the  terminal  screen,  the  positions  of  the  ships 
in  the  battle  group.  You  would  invoke  this  capability  by 
entering  the  following  in  response  to  the  guery  shewn  in 
Figure  3.81 . 

KB   —       DISPLAY  FORCE  POSITIONS      <cr> 
MR  —   "Display"  "Eattle  Group"  "Positions" 

The  specific  display  which  wculd  result  from  this  command 
depends  en  the  type  cf  coordinate  system  in  use.  If  the 
polar  coordinate  system  is  currently  being  utilized,  then 
the  Figure  3.89  shows  a  representative  display  of  the 
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information    you    will   observe.  If   the   cartesian    coordinate 

system  is  teing  utilized,  then  the  presentation  shewn  in 
Figure  3.90  is  representative  of  the  information  you  will 
observe. 


BATTLE   GROUP  POSITIONS 
(POLAR) 

ID                                 NAME  3NG                               RNG 

1  PAUL    I    FOSTER  90                              50000 

2  CARL    VINSON  0                                          0 

3  CALIFORNIA  0           100000 

***  PEFSS  RETURN  TO  CONTINUE*** 


Figure  3,89    Eattle  Group  Positions  —  Polar. 


Let* s  examine  the  information  in  the  presentation  shewn  in 
Figure  3.89.  You  should  first  notice  that  any  leading 
zeros  are  emitted.  Therefore,  "090"  would  be  displayed 
"90,"  and  "000"  would  be  displayed  "0."  Such  is  the  case 
with  the  positions  cf  FOSTEE  and  CARL  VINSON,  respectively. 
The  positions  shewn  in  the  presentation  for  the  polar  coor- 
dinate system  show  bearings  and  ranges  from  "ZZ."  You  can 
see,  then,  from  the  informaticn  in  Figure  3.89,  that  CARL 
VINSON  is  at  "ZZ,"  as  her  bearing  and  range  are  both  ZERO 
(0)  .  From  this  display,  you  can  determine  the  following: 
PAUL  J  POSTER  is  bearing  090  degrees  true,  range  50,000 
yards  frcm  "ZZ,"  CABI  VINSON  is  at  "ZZ,"  and  CALIFORNIA  is 
tearing  000  degrees  true,  range  100,000  yards  frcm  "ZZ." 
In  all  cases,  ycu  cculd  substitute  CARL  VINSON  for  any  "ZZ" 
designation.  The  cartesian  positions  are  displayed  as 
shown  next. 
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BATTLE  GRCUP  POSITIONS 
(CA  ETESIAN) 


ir 
1 

2 
3 


UNIT 

PAUL    F    FCSTEE 
CARL    VINSON 
CALIFORNIA 


QUAD 

W 
G 

B 


X-POSIT 

100 

20 
100 


Y-POSIT 

90 
10 

50 


***    PRESS    RETURN    TO    CONTINUE    *** 


figure   3.90        Battle  Group   Positions   —    Cartesian. 

As  we  saw  in  the  example  of  polar  positions, 
there  are  NO  leading  zeros  shewn  in  the  numbers.  Ycu  could 
derive  the  following  from  the  information  shown  in  Figure 
3.90.  PAUL    F      FOSTER      is    in      the      WHITE    quadrant,         with 

x-positicn    100    and       j-position   90.  CARL    VINSON      is    in   the 

GREEN  quadrant,  with  x- position  20  and  y-position  10. 
CALIFORNIA  is  in  the  ELUE  quadrant,  with  x-positicn  100  and 
y-positicn    50.  Unlike  the   example    for    polar   positiors,    it 

is  net  clear  from  the  information  shown  in  Figure  3.90, 
which  unit  is  at  "ZZ."  If  you  were  using  the  cartesian 
coordinate  system,  ar.d  desired  to  determine  which  unit  is  at 
"ZZ,"  you  should  move  to  the  SENSOR  module  and  display  the 
battle  group  positions  on  the  graphics  monitor.  This  would 
give  ycu  a  tetter  feel  for  the  "relative"  positioning  of  the 
units. 

To  continue,  after  viewing  the  battle  grcup 
positions,  you  would  enter  the  cemmand  shown  in  Figure  3.80. 
So   dcing    will   return    you   to    the   query   shown   in   Figure    3.79. 

d.      Display    cf  Force    Missions 

This  feature  of  the  STATUS  module  allows  ycu  to 
view      the   current      primary      and      secondary    missions      of      the 


150 


battle  group  units.  Aside  from  the  informational  value  of 
this  display,  you  can  get  the  feel  for  a  key  element  cf  the 
communications  makeup  of  the  battle  group.  The  primary  and 
secondary  aissions  for  each  unit  serve  as  the  keys  to 
assigning  those  units  to  the  various  battle  group  communica- 
tions nets.  Therefore,  as  a  unit  has  a  primary  mission  cf 
AAW,  and  a  secondary  mission  of  ASW,  she  would  be  included 
in  all  AAW  and  ASW  circuits,  as  well  as  circuits  designated 
for  the  Fcrce  as  a  whole.  To  display  the  battle  grcup 
missions,  make  the  following  entry  in  response  tc  the  query 
shown  in  Figure  3.79. 

KE   —  DISPLAY  FORCE  MISSIONS       <cr> 

VE   --   "Display"  "Battle  Group"  "Mission  Areas" 

Figure  3.91  (adjusted)  shows  the  composition  of  the  battle 
group  Missions  display.  It  is  essentially  in  two  groups  of 
columns  shewing  the  ship  names,  primary  and  secondary 
missions  in  each  of  tie  two  columns. 


*  BATTLE  GECUE  MISSIONS  * 
NAME  PRI  SEC 


PACL  F  FOSTEP 
CAEL  VINSON 
CALIFORNIA 


ASW 
STR 
AAW 


ASU 
AAW 
ASU 


***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.91    Battle  Group  Missions. 


The  representation  shown  i r  this  figure  is  str aightf oward. 
Table  V  shews  the  definitions  cf  the  various  mission  area 
abbre viatiens. 
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TABLE  V 
Hissicn  Areas 


Abbreviation 

NNN 
AAH 
ASW 
ASU 
AMW 
STR 
LOG 


Mission  Area 

No   Mission 

Anti-Air      Warfare 
Anti-submaring   Warfare 
Anti-Surface    warfare 
Amphibious    Warfare    (NGFS) 
Strike    Warfare 
Loaistic    Support 


lou      can   return      to    the      module   menu       (Figure   3.79),         after 
viewing   the      mission    informations   in      the   display      of   Figure 

3.91,  by  entering    "RITUEN,"    as    shown    in    Figure   3.80. 

€.      Display    cf   Force   HAEFOON   Capable   Units 

This  feature  of  the  STATUS  module  allows  ycu  to 
display  the  names  cf  the  units  in  the  battle  group  which 
have    a    HAEFCON    capability.  To    initiate   this  feature,      you 

would   enter   the      following    command   ir.    response      to   the   query 
shown    in    Figure    3.79. 

KB      —  DISPLAY    FOECE    HARPOON  <cr> 

VE      —     "Display"   "Battle   Group"    "HARPOON  Weapons" 

This    ccmnand      would    result      in    the      display   shown      in   Figure 

3.92.  Ihe   compositicn   of    this    display    is    straightf cward   in 
that    cnly   the  names    cf   the    HARPOON   capable    units    are    shewn. 

If    there    were  no   HARPCON  capable      units   in   the   battle   group, 
ycu    wculd    see   the   following    on   the   terminal   screen. 

*****************    NONE    FOUND    ***************** 
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*   BATTLE    GECUF    HAEECCN    CAPABLE    UNITS* 

<ship  name> 
<ship  rame> 
<ship    name> 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure   3.92        Harpoon   Capable   Units. 

Following  this  display,  you  can  continue,  and  return  tc  the 
irodule  menu,  by  entering  CARRIAGE  RETURN,  as  shown  in  Figure 
3.80. 

f.      Display   cf   Force   TOMAHAWK   Capable    Units 

Similar  tc  the  previous  section,  this  feature  of 
the  STATUS  module  allows  ycu  to  display  the  names  of  the 
units  in  the  battle  grcup  which  have  a  TOMAHAWK  weapons 
capability.  To   display   this      information,      you    would   make 

the    fcllcwir.g   response   to  the   query   shown   in    Figure    3.79. 

KE      —  DISPLAY    FOECE    TOMAHAWK  <cr> 

VE      —      "Display"   "Battle    Group"    "TOMAHAWK   Weapons" 

The  display  you  would  initiate  in  making  this  response  is 
shown    in    Figure      3.93.  As    ycu    saw    with      the   HARFOCN    capa- 

bility display,  only  the  names  of  the  ships  with  this  capa- 
bility   are    shown. 

If  there  had  been  nc  units  in  the  battle  group  with  this 
capability,    then   the    following    would   be   displayed. 

*****************    NONE    FOUND    ***************** 

When  vcu  are  finished  with  this  information,  you  can  return 
tc  the  icdule  menu  by  entering  "RETURN,"  as  described  in 
Figure    3.80. 
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*    BATTLE    GFCUP   TOMAHAWK    CAPABLE    UNITS    * 

<ship  nama> 
<sh^P  nane> 
<ship    name> 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure   3.93        TOHAHAWK   Capable   Onits. 

g.      Display    cf  Force   TASS   Capable   Units 

This  capability  of  the  STATUS  module  allows  you 
tc  display  the  names  cf  the  units  in  the  battle  group  with  a 
TASS  capability,  alcrg  with  the  name  of  the  specific  model 
cf   the   equipment  onbcard.  To      initiate   this   feature,      you 

would   enter  the    following  in   response      to   the   query   shown   in 
Figure    3.79. 

KE      —  DISPLAY    FORCE    TASS  <cr> 

VR      —      "Display"    "Battle    Group"    "TASS    Systems" 

The    information      shown   in  Figure      3.94   is      representative   of 
the    display    you    would   observe   after   making   this   entry. 


*    BATTLE    GROUP    TASS    CAPABLE    UNITS    * 

PAUL   F    FOSTER  AN/SQR-19     (IMPROVED    TACTASS) 

ALBERT    DAVID  AN/SQR-13     (TACTASS) 

***    PRESS    RETURN    TO    CONTINUE    *** 


i 


Figure  3.94    TASS  Capable  Onits. 
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If  no  units  with  a  TASS  capability  were  found  to  be  in  the 
battle  group,  the  following  would  be  displayed  on  the 
terminal  screen. 

**4********44****  NCNE  FOUND  ***************** 

When  ycu  are  through  reviewing  the  information  shown  in 
Figure  3.94,  you  can  return  to  the  module  menu  by  entering 
"CARFIAGI    RETURN,"    as   shown    in    Figure    3.80. 

h.      Display    Composite    Warfare   Commander   Organization 

This   feature     ofthe   STATUS    module   allows      ycu   to 
display     the  current     CWC   organization.  This    display     is 

initiated  by  making  the  following  entry  in  response  tc  the 
query   shewn   in    Figure   3.79. 

KB      —  DISPLAY    COMMAND  <cr> 

VR      --      "Eisplay    "    "CWC   Organization" 

As  a  result  of  making  this  entry,  you  would  see  the  informa- 
tion shown  in  Figure  3.95,  which  is  representative  of  a 
normal   CfiC   organization. 

When  you  are  through  with  this  information,  and  are  ready  to 
return  tc  tie  module  menu,  you  should  enter  CARRIAGE  RETURN, 
as   shewn   in   Figure    3.80. 

3.      STATUS    Module  zz  Change   Option 

The   formats      for  the      CHANGE   commands     are   shown     in 
Figure   3.96.  These  commands   can      be   displayed    by    entering 

the    following   in  response  tc   the    query   shown   in    Figure    3.79. 

KB      —  CHANGE  <cr> 

VR      —      "Change    Database"    "Carriage   Return" 
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HERE  IS  A  LIST  OF  THE  COKFCSITE  WARFARE  COMMANDER  OR- 
GANIZATION YO0  HAVE  ENTERED. 

CViC  CCR  ORGANIZATION  EMEARKED  IN 

CIC  COMCRUDESGRU  3        NIMITZ 

AAWC  CO.  GRIELEY           GETDLEY 

ASWC  CQMDESrCN  23           MERRILL 

ASUWC  CO,  MERBILL           MERRILL 

ABEC  CO,  NIMITZ             NIMITZ 

LIC  CO,  PAUL  F  FOSTER     PAUL  F  FOSTER 

SEC  CCMSOBrCN  4            NIMITZ 

EWC  CO,  GRIDLSY            GRIDLEY 


***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3.95    Composite  Warfare  Coaaander  Organization. 


"CHANGE"  COMMANDS: 

CHANGE     (UNIT    NAME)  CHANGE    DATABASE    FOR    A    UNIT 

(ENTER   UNIT    NAKE    WITH  CUT    PARENS    E.G.     CHANGE    NIhlTZ. 
A    MENU    WILL     EE    PROVIDED    FOR    SELECTION    OF    SPECIFIC 
ELEMENT) 

CHANGE    FORCE    POSITIONS  CHANGES    POSITIONS    FOR    All 

UNITS 

CHANGE  CCMMANC  CHANGE  CWC  ORGANIZATION 


***  PRESS  RETURN  TO  CONTINUE  *** 


figure  3.96    STATUS  Hodule  —  CHANGE  Commands. 

When  ready,   you  would  continue  by  entering  CARRIAGE  RETURN, 
as  shewn  in  Figure  3.£0.     Ycu   will  then  be  presented  with 
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the  query  fcr  your  STATUS  module  command,  as  shown  in  Figure 
3.81.  Even    though      you      have      just   reviewed      the      CHANGE 

command  formats,  ycu  are  not  limited  to  making  a  CHANGE 
command,  and  are  free  to  utilize  either  DISPLAY,  CHANGE,  or 
REMARKS.  We    will      look      at   each      of      the   CHANGE      command 

cpticns   individually. 

a.      Changing   a   Unit's   Database 

If  you  desire  to  change  s  unit's  database,  you 
should  make  the  following  entry  in  response  to  the  query 
shown    in   Figure    3.81.  As    an      example,      we    have    decided   to 

CHANGE    the    FOSTER'S    database. 

KE      —  CHANGE    UNIT    PAUL    F    FOSTER  <cr> 

VB     —  "Change   Data  rase"    "Unit"    "PAUL    F   FOSTER" 

In  order  to  identify  the  specific  capability  in  the  FOSTER'S 
database  you  desire  tc  change,  ycu  will  be  presented  with  a 
menu  listirg  the  titles  of  the  capabilities  in  the  datatase. 
This    menu   is  shown    in   Figure    3.97. 

As  a  point  of  interest,  the  capabilities  listed 
in  Figure  3.97  show  tie  elements  of  the  master  database  that 
are  stored  for  each  unit,  with  the  exception  of  the  avail- 
able UEF/HF  radios,  addressed  in  the  COMMS  module.  If  the 
unit  t>as  not  in  the  master  database,  these  items  were  the 
capabilities  which  ycu  input  manually  for  that  unit.  The 
CFeraticrs  involved  with  changing  a  unit's  database  will 
utilize  the  same  menus  which  you  utilized  in  performing  this 
manual  entry.  They  are  all  shewn  in  the  section  under  the 
BUILD  ECDULS  OPERATIONS  heading,  which  covers  manual  entry 
of   the    datatase.      Here   is   hew    it    will    work. 

The  desired  response  to  the  menu  shown  in  Figure 
3.97  would  be  the  number  corresponding  to  the  capability 
which    ycu   desire    to    change      in    the   unit's    database.  There 

are    generally  two      categories   of    option.  First,         you   can 
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*  DATABASE  ENTRY  OPTIONS  * 


1 
2 
3 

4 
5 
6 

7 
8 

9 
10 

1  1 

12 
13 
14 
15 


HDIL 

GRCUF 

SCCAD 

PRIMA 
SECCN 
HAFFC 
PRIMA 
SECCN 
FAEAR 
SUE?  A 
PRIMA 
FAEAR 
SECCN 
FAIAR 
tfC.  C 
NO.  0 
SAICO 
GUN  H 


NUMBER 

COMMANDER 
EON    CCMMANEER 
RY    MISSILE    SYSTEM 
EARY    HISSIIE    SYSTEM 
CN    CAPABILITY 
RY    AIR    SEAFCH    RAEAR 
EARY    AIR    SEARCH 

CE    SEARCH    RADAR 
RY    FIRE    CCMRCL 

DARY    FIRE    CCNTROI 

F    UHF    RADICS    ONBD 
F    HF    RADICS    ONBD 
H   CAPABILITY 
FAPONS    SYSTEM    ONBD 


16  PHALANX    CAPABILITY 

17  TOMAHAWK    CAPABILITY 

18  HSLO    CAPABILITY 

19  H2LO    CAPABILITY    CNED 

20  SONAR    SYSTEM    ONEE 

21  IVDS    CAPABILITY    CNED 

22  TASS    SYSTEM    ON3D 

23  ASM    ROCKET   CAPABILITY 

24  TORPEDO    CAPABILITY 

25  MAXIMUM    SPEED 

26  SLQ-32    CAPABILITY 

27  PRIMARY    MISSION    AREA 

28  SECONDARY    MISSION    AREA 

29  ALL    OF    THE    ABOVE 


Figure  3.97        Quit   Database   Capability   Options. 

specify  the  specific  capability  you  desire  to  change 
(numbers  1  -  28),  CB,  you  can  change,  or  more  exactly, 
rewrite,         the       unit's     entire   database.  In      the      f crier 

category,  you  would  be  gueried  for  the  capability  you 
specify,  with  the  cpticn  menu  corresponding  to  that  capa- 
bility, and  then  returned  to  the  STATUS  module.  In  the 
latter  case,  you  would  be  recompiling  the  unit's  database, 
and  wculd  therefore,  sequence  through  ALL  of  the  capability 
lenus,  and  then  returned  to  the  STATUS  module.  After  you 
have  completed  with  the  opticn  you  select,  you  will  be 
queried  as  to  whether  you  desire  to  make  this/these  chances 
a  permanent  part  of  the  master  database.  The  intent  of 
this  feature  is  to  allow  you  to  maintain  a  real  time  data- 
base, reflective  of  the  unit's  capabilities,  NOW.  Mere 
often  than  not,  these  changes  would  be  of  a  temporary 
nature.  Should  however,  the  change(s)  you  make  be  of  a 
permanent  nature,  then  ycu  could  pramanently  change  the 
irastei   database.         It  is   your   choice. 
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If  you  desired  to  change  the  PRIMARY  MISSILE 
SYSTEM  capability  of  the  unit  you  designated  in  response  to 
the  query  shown  in  Figure  3.81,  you  would  make  the  following 
entry    frcm   the   menu. 

KB      —  4  <cr> 

VR      —      "Four"   "Carriage   Return" 

Entering  this  command  woud  result  in  the  display  of  the 
HISSIIE    SYSTEM       OPTICUS    menu      shown    in      Figure   3.25.  You 

would  designate  the  system  the  unit  new  has  by  indicating 
the  appropriate  system  from  the  menu.  (This  is  covered,  in 
detail,  under  BUILD  F.CDULE  OPERATIONS.)  Table  VI  can  serve 
as  a  guick  reference  to  the  menus  which  will  appear  when  you 
designate   a    particular  capability  change. 

Once  you  have  made  your  change,  the  query  shewn 
in  Figure  3.98  will  be  presented,  as  has  already  been 
discussed.  If  you    enter    YES    tc   this   query,    the   change    you 

have  just  made  will  become  a  part  of  the  master  database. 
If  you  enter  NO  to  this  query,  the  change  will  be  retained 
in    the    battle   group    database   ONLY. 


???    wCULE    YOU    LIKE   TO    MAKE    THIS    CHANGE    TO    EE    PERMA- 
NENTLY   H£DE    TO   THE    MASTER    DATABASE    ??? 
(YES/NO) 


Figure    3.98        Query   —   Hake   a  Capability   Change    Permanent. 


As   a    review,        the    fcrmat  for   this  response   is      shown   in   the 
following  example. 


KE     ~  YES      <cr>  or 

vR      —        "Affirmative"        or 


NO  <cr> 

"Negative" 
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TABLI  YI 
Reference  of  Database  Capabilities  vs. 


Capability 

1  —  HULL    NUMBER 

2  —  GROUP   COMMANDER 

3  —  SQUADRON    COMMANDER 

U       —  ERIMARY    MISSILE    SYSTEM 

5  —  SECONDARY    MISSILE    SYSTEM 

6  —  HARPOON    CAPABILITY 

7  —  ERIMARY    A3B    SEARCH    RADAR 

8  —  SECONDARY    AIR    SEARCH    RADAR 

9  —  SURFACE    SEARCH    RADAR 

10  —  ERIMARY    FIRE    CONTECI    RADAR 

11  —  SECONDARY    FIRE   CONTROL    RADAR 

12  ~  KO.     OF    UHF    RADIOS    ONBOARD 

13  —  NO.     OP    HF    RADIOS    ONBOARD 

14  ~  SATCOM    CAEABILITY 

15  ~  GUN    WEAPONS    SYSTEM    CAPABILITY 

16  —  EHALANX    CAEABILITY 

17  ~  TOMAHAWK    CAEABILITY 

18  —  HELO    CAPAEILITY 

19  —  EELO    CAPAEILITY    ONBOARD 

20  —  SONAR    SYSTEM    ONBOARD 

21  —  IVDS    SYSTEM    ONBOARD 

22  —  TASS    SYSTEM    ONBOARD 

23  —  ASW    ROCKET    CAPABILITY 

24  —  TORPEDO    CAEABILITY 

25  —  MAXIMUM    SPEED 

26  —  SLQ-32    CAEABILITY 

27  —  ERIMARY    MISSION    AREA 

28  —  SECONDARY    MISSION    AREA 

29  —  SLL    OF    THE    ABOVE 


Option  Menus 


Option  Menu 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Fig  ure 

Figure 

Based 

Type 

Fiaure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure  3.49 

All  Menus 


3. 

19 

3. 

23 

3. 

24 

3. 

25 

3. 

25 

w  m 

26 

3. 

27 

4 

27 

3. 

29 

"3 

30 

3. 

30 

3. 

31 

3. 

32 

3 

— -  m 

34 

3. 

35 

3. 

36 

3. 

37 

•3 

38 

on 

HELC 

3. 

41 

3. 

42 

3. 

43 

3. 

44 

3. 

45 

3. 

46 

3. 

47 

3. 

49 

t.   Changing  Force  Positions 

The  cnly  "Force"  elements  you  can  change  are  The 
positions  of  the  units.  If  you  desire  to  change  the  posi- 
tions of  the  units  in  the  force,  you  would  make  the 
following  entry  in  response  tc  the  query  shown  in  Figure 
3.81  . 

KE   —  CHANGE  FORCE  POSITIONS    <cr> 

VE   —  "Change  Database"  "Eattle  Group"  "Positions" 
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The  first  view  that  will  be  presented  in  response  to  this 
entry  is  either  that  shown  in  Figure  3.89  (if  POLAR  coordi- 
nate system  is  in  use),  or  Figure  3.90  (if  CARTESIAN  coordi- 
nate system  is  in  use) .  This  view  will  display  the 
positions  of  the  units  in  the  battle  group  as  thay  currently 
exist  in  the  battle  group  database.  You  will  next  be 
queried  regarding  what  position  information  you  desire  to 
CHANGE.         This    is   shewn    in    Figure   3.99. 


IF    XCC    KCULD     LIKE    TO    REVAMP    ZZ,    COORDINATE    SYSTEM,    AND 
UNIT'S    POSITIONS,    ENTER    "0",    OTHERWISE,     TO    CHANGE    A 
PARTICULAR    UNIT'S    POSITION,    ENTER    THE    ID    NUMBER    CC- 
RRESPCNCING    TC    THE    UNIT. 


I 


Figure   3-99        Query  —  Change   to   Battle   Group   Positions. 


The  desired  response  to  this  query  is  similar  to  others  you 
have    lade    requiring    the   entry   of   a   number    from  a    menu.  If 

you  enter  ZERO  (0)  to  this  guery,  you  will  repeat  the  query 
sequence  which  was  used  in  the  BUILD  module  to  initially 
establish  the  battle  group  positions.  The  first  view  you 
will  see  is  that  shown  in  Figure  3.51,  asking  for  the  iden- 
tity of  the  unit  at  "ZZ . "  This  will  he  followed  by 
queries  for  identification  of  coordinate  system,  and  posi- 
tions of  each  unit  in  the  battle  group.  (These  sequences  are 
covered  in  detail  in  the  section  on  BUILD  MCDULE 
CPERATICNS.) 

If  ycu  desire  to  change  only  the  position  of  a 
particular  unit,  you  would  enter  the  number  corresponding  to 
that  unit,  from  the  query  shown  in  Figure  3.89,  or  Figure 
3.90.  Ycu  would   then   begin      the   query   sequence    for   either 
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polar  ci  cartesian  pcsition  determination,  as  appropriate, 
with  the  views  shown  in  Figure  3.55,  or  Figure  3.60,  respec- 
tively. Cnce  completed,  irrespective  of  the  opticn  chosen 
(all  cr  individual  unit)  ,  you  will  be  returned  to  the  STATUS 
module   menu    (Figure    3.79)  . 

c.      Changing    the  CWC   Organization 

If  ycu  desire  to  change  all  or  part  of  the  CWC 
crgarizaticnal  structure,  you  would  make  the  following 
response  to   the    query  shown    in   Figure   3.81. 

KB      ~  CHANGE    COMMAND  <cr> 

VR      —      "Change    Database"    "CWC   Organization" 

Cn  making  this  response,  ycu  will  be  presented  with  a 
display  cf  the  current  CWC  Organization,  an  example  of  which 
is    shewn      in  Figure    3.67.  When    you   continue      by    entering 

CARRIAGE  RETURN,  as  shown  in  Figure-  3.80,  you  will  te  asked 
if   those   assignments   are  correct.  This    query    is   shown   in 

Figure      3.68.  Based     cn      your      response      to      this      query 

(YES/NO)  ,  you  will  follow  the  query  sequences  previously 
discussed  in  the  BUIIE  module,  for  making  corrections  to  the 
CWC    Organization.  If    you    need      to    review   these   sequences, 

you  should  refer  to  the  "List  of  Figures"  for  the  title  cf 
the      vie*/guery    composition      ycu      desire.  When   ycu      have 

completed  making  charces  to  the  CWC  Organization,  you  will 
fce   returned   to   the    S1ATUS   module    menu    (Figure   3.79). 

a-       STATUS    Module   zz   REEABKS    Option 

This  feature  of  the  STATUS  module  allows  you  to 
enter  descriptive  remarks  to  be  included,  and  displayed, 
with    a      particular    unit's      database.  The      format    for      the 

EEMAEKS    cemmand    is    shewn   in      Figure   3.100.  The    display   of 

the  cemmand  format  is  obtained  by  making  the  following  entry 
in    response    to    the    query  shown    in    Figure    3.79. 
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KB       —  EEMARKS  <cr> 

VR      —      "EEMARKS"    "Carriage    Return" 


"EEKAEKS"   COMMANDS: 

REMARKS     (UNIT    NAME)  ENTER    REMARKS    FOR    A    UNIT 

(EMEB    THE    NAME    WITHOUT    PARENS,    E.G. 

REMARKS    JOHN    YOUNG) 


Figure  3.100         Status    Module  —    REMARKS   Command. 


The  format  cf  the  command  is  straightf oward,  "REMARKS"  is 
always  followed  by  the  nam e  of  a  ship  in  the  battle  group. 
When  ycu  continue,  by  entering  CARRIAGE  RETURN,  as  shewn  in 
Figure  3.30,  you  will  b9  presented  with  the  query  shown  in 
Figure      3.101.  As      an   example,         if    you      wanted    tc      enter 

remarks  for  CARL  VINSON,  the  following  would  te  your 
response   tc   the    query   shown    in   Figure    3.81. 

KE    --  BEMJBKS   CARL    VINSON  <cr>  or 

REMAEKS    VINSCN  <cr> 

VB      —  "Remarks"    "CARL    VINSON"  or 

"Remarks"    "VINSON" 

Your  entry  would  be  followed  with  the  query  for  the  remarks, 
which    is   shewn    in  Figure   3.101. 

REMARKS      can     ONLY      be   entered      from      the      KEYBOARD.  The 

language  flexibility  for  voice  input  restricts  input  of 
ether   than   system   commands.  The      form   of   your    REMARKS   can 
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REMARKS  FOR  CARL  VINSON 


YOU  CAN  ENTER  UP  TC  25  CHARACTERS  OF  REMARKS.   FLZ&3E 
CCNFINE  YOUR  REMARKS  TO  THE  FOLLOWING  BOUNDARIES. 


V  V 

(area    for    remarks) 


Figure   3.101         BEMARKS    Input. 

take  ce  anything  ycu  desire  (e.g.  Embarked  Commander, 
Capability  Impairment,  Schedule,  etc.) ,  provided  the  field 
of  the  statement  is  within  the  boundaries  shown  in  tha 
guery.  Should   you    exceed    the      confines   of   the    boundaries, 

the  information  to  the  right  cf  the  right  guide  arrow  will 
not   be      read  into   the  system.  Once   you   have      entered    the 

remarks,  they  will  fcecome  a  permanent  part  of  that  unit's 
database,  and  will  be  included  in  the  database  display 
invoked    with  the   "DISPLAY   UNIT"    command.  Once    the   remarks 

have  been  entered,  ycu  will  be  returned  to  the  module  menu 
(Figure    5.79). 

I.       CCMMS    MODULE   OPERATIONS 

This  feature  of  the  DSS  basically  allows  you  to  dc  two 
things.  First,  you  can  maintain  the  numbers  of  "Available" 
UHF/fiF   radics   onboard   each    battle      group   unit.  The    second 

function  of  this  module  is  to  allow  you  the  opportunity  to 
display  the  composition  of  a  battle  group  communications 
net.  Ihe   display   cf  the      communications   net  reguires  that 

you    have    a      graphics    capability.  If   ycu   do      not    have   one, 

you    must      restrict    your   use    of      this    module   to      managing   the 
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cumbers   cf    available      radios.  You   would   invoke      the   COMMS 

module,      frcm  the   query    shown   in      Figure    3.6,      by    making   ^he 
following   entry. 

KE     —  COMMS      <cr> 

VS      —      "Cousins   Module" 

This    ccmmand  will      cause  the   CCMMS   module   master      menu   to   be 
presented   on  the  terminal  screen.  The    format  of   this    menu 

is   shewn   in   Figure    3.102. 


*     EATTLE    GROUP    ^SSET    MANAGEMENT    * 
*    DECISION     SUPPORT    SYSTEM    * 

*    COMMS    MODULE    * 

IN    THIS    MODULE,    YOU    HAVE    THE    FOLLOWING    GENERAL 
CFIICNS: 

1  —    CHANGE    THE    NUMBER    OF    AVAILABLE    RADIOS    ONBOARD    A 

CNIT 

2  —  DISPLAY  THE  PARTICIPANTS  IN  A  BATTLE  GROUP  RADIC 

NET 

3  —    FETDRN    TO    THE    MAIN    MODULE 

(SELECT    CNE    OF   THE    ABOVE     (1,    2,    OR    3)) 


Figure    3.102        COHHS    flodule   Options   Menu. 


The  correct  response  to  this  query  is  the  number  corre- 
sponding tc  the  option  you  desire.  If  you  desired  to 
display  the  participants  of  a  radio  net,  zhe  following  is  an 
example    cf    a  correct   entry. 

KB      —  2  <cr> 

VF      --        "Two"    "Carriage   Return" 
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If  an  error  were  to  cccur  in  caking  this  response,  ycu  would 
be  simply  directed  to  reenter  your  response  (1,  2,  cr3) . 
We   will    next  look   at   each  of   the   available    module    options. 

1 .      CCMES      Module     —      Change   the      Number      of      Available 
Eadios 

The  aim  of  this  feature  of  the  COMMS  module  is  to 
allow  ycu  to  maintain  a  real  time  estimate  of  the  numbers  of 
available  UHF/HF  racics  onboard  the  units  in  the  battle 
group.  The   intent      is  then   to    compare      these   numbers   with 

the   numbers   of      installed  radios   on   the      ships.  The    query 

sequences  associated  with  the  determination  of  either  DHF  or 
HF   available     radios    will      be    discussed      individually.  In 

respcr.se  to  the  query  shown  in  Figure  3.102,  you  would  make 
the    fcllcwirg  entry   tc   invoke   this    module    feature. 

KB      —  1  <cr> 

VR   —   "One"  "Carriage  Return" 

The  next  query  that  wll  be  presented  will  be  to  identify  the 
unit  tc  which  this  change  will  apply.  The  format  for  this 
query,  with  a  representative  composition  of  ships,  is  shown 
in  Figure  3.103. 


?  FOR  KHICH  BATTLE  GROUP  UNIT  WILL  THIS  CHANGE  APPLY  ?   | 

! 

CARL    VINSON  PAUL    F    FOSTER  CALIFORNIA  | 

I 

I 

i 

Figure    3-103        Query   —   Unit   Whose    Radios   are  to    be   Changed. 


The  entry  of  the  name  of  the  unit  must  match  the 
name  cf  cne  of  those  ships  in  the  list  following  the  query. 
The    system    will      check   your    entry  against    the     list,      and   if 
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there  is  no  match,  ycu  will  be  asked  to  reenter  tha  name  of 
the  applicable  unit.  The  next  query  will  address  whether 
you  desire  to  ADD  or  DELETE  either  a  UHF  or  HF  radio.  The 
format  for  this  query  is  shown  in  Figure  3.104,  and  for 
example,  suppose  you  wanted  tc  change  the  number  of  radios 
en  CAIIFCJNIA. 


FOB  CALIFORNIA 
WHICH  OF  THE  FOLLOWING  OPTIONS  WOULD  YOU  LIKE  TO  USE 

1  —  ADC  AN  AVAILABLE  UHF  RADIO 

2  —  DELETE  AN  AVAILABLE  UHF  RADIO 

3  —  ADC  AN  AVAILABLE  HF  RADIO 

U  --  DELETE  AN  AVAILABLE  HF  RADIO 

(ENTER  1,2,  3,  CB  4) 


Figure   3.104        Query  —    ADD   or  DELETE   a   UHJ/HF   Radio. 


The  desired  response  to  this  query  is  straightf oward. 
Ihese  options  will  allow  the  change  of  only  one  (1)  radio  at 
a  time.  Additionally,  the  system  will  check  the  change  you 
are  naking  to  ensure  two  things.  Firs1:,  you  cannot  increase 
the  number  cf  available  radios  beyond  the  database  number  of 
installed    radios  of    any  type.  Second,    you   cannot    decrease 

the      numbers  of      available      radios      below    zero      (0) .  The 

controlling  limits  are  determined  by  the  numbers  of  UHF  and 
HF  radios  in  the  database.  If  those  numbers  are  incorrect, 
or  there  has  been  a  change  to  them,  you  can  input  that 
change    in      the    STATUS   module.  If      need    be,      refer      tc   the 

appropriate  topic  in  that  module  to  effect  a  change,  if 
required.        You    can    also   view   the   number   of   installed    radios 
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cnboard  a  unit  by  displaying  its  database.  This  is  dene  in 
the  STATUS  module  as  veil.  Each  time  you  attempt  to  change 
the  number  cf  radios  cnboard  a  unit,  you  will  see  a  summary 
of  the  current  datatase  regarding  the  installed  and  avail- 
able DHF  and  HF,  after  each  entry. 

If  there  is  a  checking  problem  with  the  onboard 
numbers,  cne  of  the  warnings  shown  in  Figure  3.105  will  be 
presented,  as  appropriate. 


CALIFORNIA  ALREADY  HAS  ALL  EER  UHF/HF  RADIOS  AVAILAELE 

(If  the  number  of  available  radios  equals  the  number 
of  installed  radics,  and  you  attempt  to  add  a  radio) 

CALIFORNIA  HAS  KC  UHF/HF  RADIOS  AVAILABLE  ALREADY 

(If  the  number  of  available  radios  is  already  zero 
(0) ,  and  you  attempt  to  delete  a  radio.) 


Figure  3.10  5    Warning  —  Radio  Numbers  Mismatch. 

Once  the  transaction  (adding  or  deleting  a  radio)  has  been 
completed,  you  will  be  returned  to  the  module  master  menu 
(Figure  3.  102)  . 

2  .   Displa  y  of  a  Communi cations  Net 

If,  in  response  to  the  query  shown  in  Figure  3.102, 
you  desired  to  display  the  composition  of  a  communications 
net,  ycu  would  enter  two  (2).  As  this  display  will  he  on 
the  graphics  monitor,  you  will  be  first  aska-d  which  monitor 
you  desire  to  use.  The  format  for  this  query  is  shown  in 
Figure  3.108,  and  the  desired  response  is  the  number 
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corresponding  to  the      nonitcr   you   want   to      use.  Ycu    would 

next  be  presented  with  a  listing  of  the  battle  group  commu- 
nications plan.  This  plan  contains  the  names  of  twenty 
(20)  circuits,  along  with  the  frequency  range  of  the 
circuit,  and  the  name  of  the  Net  Control  Station  (NECOS) . 
The    fcrmat    for   this    iienu  is    shown   in   Figure    3.106. 


r 

*  BATTLE  GECUP  COMMUNICATIONS 

CIRCUITS  * 

~\ 

CKT 

IE           NET  NAME 

FREQ 

NECOS 

1 

TF/TG  COMMAND 

HF 

OTC 

2 

TF/TG  ORESTES 

HF 

OTC 

3 

TF/TG  ORESTES 

UHF 

OTC 

4 

AAW  CMD  Z    RPT  PRIMARY 

HF 

AAWC 

5 

AAW  CMD  &    RPT  SECONDARY 

HF 

AAWC 

6 

AAW  CMD  Z    RPT 

UHF 

AAWC 

7 

EW  REPORTING 

HF 

EWC 

8 

EW  REPORTING 

UHF 

EWC 

9 

SSSC 

HF 

ASUWC 

10 

SAC  NET  ALFA 

UHF 

ASUWC 

11 

SAC  SET  BRAVO 

UHF 

ASWC 

12 

VP  COORDINATION 

UHF 

ASWC 

13 

LINK  11 

HF 

AAWC 

14 

LINK  11 

UHF 

AAWC 

15 

LINK  14 

HF 

AAWC 

16 

LINK  14 

UHF 

AAWC 

17 

PRITAC 

UHF 

OTC 

18 

PRI  CI 

UHF 

(S) 

OTC 

19 

DATA  LINK  COORDINATION 

HF 

AAWC 

20 

DATA  LINK  COORDINATION 

UHF 

AAWC 

(SELECT 
i   , 

THE  APPROPRIATE  CIRCUIT  ID  NUMBER 

(CKT 

ID)) 
i 

Figure    3.106        Battle  Group   Coaaunications  Circuits. 

The     result      cf   this      entry      will      be   a      fan      shaped 
display   en-  the    graphics   monitor.  Wi-hin   this   fan,    will   be 

the      net  control      station,         and  the      unit      on      which    it      is 
embarked,    at  the  hub.  There   will   then   be   lines    projecting 

cutwaids,    at  the   end   cf   which    will    be    the    names   of    the    units 
who    are    participants   en   that   net.  Finally   the    name    of   the 
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circuit  being  displayed  will  be  shown  across  the  bottom  of 
the    monitor   screen. 

The   display    will  be    color   keyed   to   highlight    several 
considerations      about     the      circuit.  As      was      mentioned 

earlier,  the  mission  area  assigned  to  a  unit  determines  its 
participation   on  a    force  radio   circuit.  Those   units    whose 

primary  mission  requires  them  to  be  on  the  net  will  be 
connected  tc  the  hub  with  "green"  lines.  Those  units  whose 
secondary  missions  require  them  to  be  on  the  net  are 
connected   tc  the   hub    with   "cyan"    lines.  The  overall    color 

cf  the  hut  and  the  circuit  name  indicate  the  frequency  of 
the    circuit.  If      the   color    is    "yellow,"    the      circuit   is   a 

OHF   net.  If    the   eclor   is    "red,"   the   circuit  is    an   HF   net. 

The  final  information  which  is  color  keyed,  applies  tc  UH? 
nets.  It   is    conceivable    that   a      unit   may   be  required  on   a 

particular  UHF  net,  however,  due  to  range  from  the  NECCS, 
participation  MAY  be  impaired.  To  accent  this  possibility, 
on  UHF  nets,  a  participating  unit  whose  range  is  greater 
than  35  nautical  miles  from  the  NECOS  will  have  its  name 
shown   in    "red."  The  normal   color    for    -che      ships'    names  is 

"yellow,"  indicating  that  the  unit  is  within  communications 
range   of      the   NECOS.  This    "legend"      information   will      be 

displayed  on  the  terminal  screen  each  time  ycu  display  a 
circuit.  The      format   for    this      legend   is   shown      in   Figure 

3.107.  When  you  have  completed  with  the  circuit  graphics 
display, 

KB      ~  <cr> 

VR   —   "Carriage  Return" 

you  would  make  the  following  entry,  and  will  be  cycled  back 
to  the  mcdule  menu  (Figure  3.102). 
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*  GRAPHICS  LEGEND  * 

DISPLAY  COLOR  DESRCRIPTION 

SHIP  NAMES  RED        OUT  OF  COMM  RNG  OF  NECOS 

YELLOW     WITHIN  COMM  RNG  OF  NECOS 

CCNNECTING 

LINES        GREEN      PRIMARY  MISSION  REQMT 

CYAN        SECONDARY  MISSION  REQMT 

NECOS  LAEEL/ 

CIRCUIT  NAME    YELLOW     UHF  CIRCUIT 

RED         HF  CIRCUIT 

***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3. 107    Communications  Display  Legend. 

J.   SENSCR  MODOLB  OPERATIONS 

The  SENSOR  module  utilizes  computer  graphics  in  allowing 
you  to  display  the  coverage  areas  of  the  various  sensors  of 
each  urit  in  the  battle  group.  As  this  module  does  use 
graphics,  if  you  do  net  have  a  graphics  capability  where  you 
are  working,  you  will  be  unable  to  operate  within  this 
module.  In  addition  to  the  sensor  coverage  displays,  you 
can  display  the  cartesian  coordinate  axes,  the  threat 
sector,  as  well  as  experiment  with  changing  the  position  of 
a  unit  and  observing  the  effects  on  coverage  area  effective- 
ness. You  invoke  the  SENSCR  module  by  making  the  following 
response  to  the  query  shown  in  Figure  3.6. 

KB   —    SENSOR     <cr> 
VR  —   "Sensor  Module" 

Unique  to  the  operations  of  the  computer  system  in  the 
WARLAE  at  NPS,   you  would  next  be  queried  as  to  your  desires 
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regarding  the  graphics  terminal  to  be  used.  This  query  is 
in  reference  to  the  terminal  number.  The  compcsiticn  of 
this  guery  is  shown  in  Figure  3.108. 


???  KHICH  RAMTEK  MONITOR  DC  YOU  DESIRE  TO  UTILIZE  ??? 

1  ~  FRONT  BAY 

2  --  REAR  BAY 

3  —  CENTER  BAY 


Figure   3-108        Selection  of  Graphics  Monitor  for   Display. 


The  desired  response  to  this  query  is  the  number  ccrre- 
spondirg  to  the  monitcr  you  intend  to  use.  Should  ther=  be 
an  error  ir.  making  this  response,  the  statement  shown  in 
Figure   3.109  will  be   presented. 


PLEASE    MAKE    YOUR    SELECTION     (1,    2,    OR    3)     FROM    THE    MENU. 
***    PRESS    RETURN    10    CONTINUE    *** 


Figure    3.109        EBBOR  —    Graphics    Monitor   Selection. 


When  you  enter  "RETUFK"  (as  shewn  in  Figure  3.111),  you  will 
again  fcs  presented  with  the  query  shown  in  Figura  3.108r  and 
can    reenter    your  response. 

The  first  time  ycu  invoke  this  module  in  a  system 
session,  the  information  shown  in  Figure  3.110,  a  summary  of 
the    capabilities  of    the   module,    will   be    presented. 
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THIS 

MANA 

YCU 

SURF 

AREA 

COVE 

EFPE 

ILAR 

SHCW 


IS 
GEME 
CAN 
ACE. 
S,  A 
RAGE 
CT  C 

10 
N    IN 


BATTLE    GROUP    ASSET    MANAGEMENT 
DECISION    SUPPORT    SYSTEM 

*    SENSOR    MODULE    * 

THE    SENSOR    MODULE    FOR    THE    BATTLE    GROUP    ASSET 
NT    DECISION    SUPPORT    SYSTEM.     IN    THIS    MODULE, 
GRAPHICALIY    DISPLAY    YOUR    BATTLE    GROUP'S     AIR, 

SUBSURFACE,    AND    FIRE    CONTROL    SENSOR    COVERAGE 
S   WELL    AS    POSITIONS,    AND    EXPERIMENT    WITH    THOSE 

AREAS    BY    MCVING     A    UNIT    AND    OBSERVING    THE 
N   COVERAGE.       THE    NECESSARY    COMMANDS    ARE    SIM- 
THOSE    YOU    UTILIZED    IN    THE    STATUS    MODULE,    AS 

THE    NEXT    FRAME. 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure    3.110        SEHSOB   Module   Description. 

While  ycu  have  seen  the  procedure  to  enter  "RETURN"  before, 
Figure  3.111  shews  the  format  for  the  entry  cf  the  RETURN 
command   as    required    tere. 


I-. . 

KB 
VR 

— 

<cr> 

"Carriage  Return" 

I 
I 

I 

_  _  i 

Figure   3.111        Entry  of    "CARRIAGE   RETURN"   or    "RETURN". 


When  you  continue,  you  will  be  presented  with  the  module 
command  options,  which  are  shown  in  Figure  3.112.  The 
entry  cf  these  commands  is  similar  to  the  format  and  struc- 
ture of  those  commands  which  you  utilized  in  the  STATUS 
Module. 

The    desired   response    to   this   query   is   ihe   one   or   two    segment 

entry   shewn   in    the    module  cemmand      options.           As    you  saw  in 
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*    SEKSOR    MCDUIE    COMMANDS    * 

DISPLAY    POSITIONS  DISPLAYS    POSITIONS    OF    AIL 

FORCE    UNITS 
SURFACE  DISPLAYS    FORCE    SURFACE 

RADAR    COVERAGE 
AIR  DISPLAYS    FORCE    AIR    RADAF 

C07  ER  AG  E 
SONAR  DISPLAYS    FORCE    SONAR 

COVERAGE 
FCRADAR  DISPLAYS    FORCE   FC    RADAR 

COV  ER  AG  E 
(AFTER    COMPLETION    OF    ANY    OF    THE    ABOVE    COMMANDS 
YOU    WILL    BE     ASKED   IF    YCU    DESIRE    TO    MOVE    A    UNIT 
CR    DISPLAY    A    THREAT    AXIS.) 

EXIT  RETURN    TO    THE    MAIN    MCDUIE 

PLEASE    ENTER     YOUR    SENSOR    MODULE    COMMAND 


Figure  3.112        SEHSOR    Hodule  —   Command  Formats. 

the    STATUS  module,       the   system    will      look    at   the    command   you 

enter,   and  break   the    command   into    segments.         The    key    tc   the 

evaluation  cf  the   command  in   this      module    is   the    first    wcrdr 

DISPLAY   or  EXIT.              We    will   discuss    each      of   these   options, 

and      their  respective      second      segments      in     the      fcllcwing 

secticns.  If      there   is      a   mistake      mad=    in     entering   your 

command,  the       statement      shown    in      Figure      3.113      will      be 
presented. 


I 

i 

PLEASE    REENTER     YCUR    COMMAND    EXACTLY    AS    SHOWN     IN    THE 
SELECTIONS    LIST. 

I 

I 
I 
I 

• 

I 
i 

Figure    3.113        EBBOR  —    SENSOR   Module   Command    Entry. 
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1.      SENSOR    Module  --  Returning   to   the    MAIN  Module 

If  you  desirad  to  return  to  the  MAIN  module,  you 
would  make  the  following  entry  in  response  to  the  query 
shown    in   Figure    3.112. 

KB      —  EXIT  <cr> 

VR      —      "Return   to   Main   Module" 


2.      SENSOR    Module  zz  Display   of   For.ce    Positions 

If  you  desired  to  display  the  positions  of  the  units 
in  the  battle  group,  ycu  would  make  ^he  following  entry  in 
response   to  the   query   shown    in   Figure    3.112. 

KB      —         DISPLAY    POSITIONS  <cr> 

VR      —  "Display"    "Positions" 

Ss  a  result  of  this  entry,  you  would  have  displayed  on  the 
graphics  monitor,  the  relative  positions  of  all  force  units, 
as         indicated        by        the  locations        of        their        names. 

Additionally,  on  the  terminal  screen,  you  would  see  a  pres- 
entation of  the  positions  of  the  battle  group  units,  as 
shown  in  either  Figure  3.89  or  Figure  3.90  (determined  by 
which  coordinate  system,  polar  or  cartesian,  is  being 
utilized).        This   display  will   be   followed    by 

***    PRESS    RETURN    TO    CONTINUE    *** 

To  continue,  you  would  make  the  entry  shown  in  Figure  3.111. 
When  ycu  continue,  you  will  have  the  opportunity  to  utilize 
the  cth*r  features  of  this  module,  enlarging  the  display, 
and  displaying  the  threat  sector  and/or  cartesian  coordinate 
axes.  The  operations  of    these      features    will   be    discussed 

in   later  topics    of    this     section.  You   will   not,      however, 

have  the  opportunity  to  move  any  units,  as  you  would  in  the 
ether   displays    of   this   module. 
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3 .      SENSOR       Module   --      Display      of      Fo rce    Sur f ace      Padar 
Coverages 

This  feature  of  the  SENSOR  module  allows  you  to 
display  the  coverage  areas  of  the  surface  search  radars  on 
each    unit   in  the  force.  In   response    to   the   query   shown   in 

Figure  3.112,  you  would  make  the  following  entry  to  initiate 
this    display. 

KB      —  DISPLAY    SURFACE  <cr> 

VR     —      "Display"    "Surface   Search   Radars" 

This  ccmirand  initiates  a  display  of  the  relative  positions 
of  each  unit  in  the  force,  with  units  identified  by  name. 
Additionally,  around  each  unit  will  be  a  circle  scaled  to 
the   surface   search   radar   installed   onboard    that   unit.  The 

radars  and  their  respective  ranges  are  shewn  in  Table  VII. 
This  display  will  be  presented  on  the  graphics  monitor.  On 
the  terminal  screen  you  will  see  the  names  of  the  units  in 
the   battle    group,      with   the    respective   onboard  radar.  The 

format  of  ■'•-he  terminal  screen  display  is  shown  in  Figure 
3.1  14. 


*    BATTLE    GROOP    SURFACE    SEARCH    RADARS    *  I 

I 
DNIT    NAME  RADAR  RANGE 

***    PRESS    RETURN    TO    CONTINUE    *** 
- i 

Figure    3.114        DISPLAY   —   Battle    Group   Surface  Search   Radars 
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r                                         '    !-■■-■ 

I 

TABLE 

VII 

DSS    Surface 

Search 

Radars 

Radar 

Range    (no) 

AN/BPS-15 
AN/BPS-  14 
AN/SPS-10 
AN/SPS-55 
AN/SPY-1 

20.0 
20.0 
30.0 
35.0 
35.0 

t         — 

i 

You  wculd  continue,  from  the  display  shown  in  Figure  3.1 14, 
by   making  the      entry    described   in  Figure      3.111.  when    you 

continue,  you  would  be  offered  the  options  of  enlarging  the 
plot,  displaying  the  threat  sector,  and  displaying  the 
cartesian  coordinate  axes.  These  features  are  discussed  in 
succeedirg    topics   of   this   section.  In    addition,      once   the 

plot  contains  the  infcrmaticn  you  desire,  you  can  experiment 
with    coverage  areas    by   moving    up     to   ten    (10)      units.  The 

process  involved  with  moving  the  units  is  discussed  at  the 
end    cf   this   section. 

4  •      SENSOR    Modul e  ~   Display   of    Force    Air    Search    Radars 

This      feature  of     the  SENSOR     module      allows    you      to 

display   the   coverage     area    of  each   of   the      air   search   radars 

en   the   battle   group    units.  You   would   invoke   this    feature 

by  making  the  following  entry  in  response  to  the  guery  shown 
in   Figure   3.112. 

KB      —  DISPLAY    AIR  <cr> 

VR      —      "Eisplay"    "Air    Search    Radars" 

This  cemmand  would  result  in  the  display  of  all  units  in  the 
battle  group,  in  their  relative  positions,  and  identified  by 
name.  Around      each  unit    would   be      a   circle   scaled      to   the 
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appropriate   air    search   radar   onboard   that    unit.  The    rang* 

characteristics   of    the   air    search   radars   in  the   database   are 
shown      in  Table      VIII   .  Additionally,        on  the      terminal 

screen,      the  composition  of    the   air   search   radars    within   the 
battle      group  would      be      displayed.  The   format      of      this 

display   is    shown   in    Figure    3.115. 


*    BATTLE    GROUP     AIR    SEARCH    RADARS    * 
UNIT    NAME  PRIMARY  SECONDARY  RANGE 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure   3.115        DISPLAY   —   Air   Search   Radars. 


TABLE   VIII 

DSS  Air    Search   Radars 

Radar  Range     (nm) 

AN/SPS-48C  220.0 

AN/SPS-49  250.0 

AN/SPS-58  250.0 

AN/SPS-4  3A  2  7  0.0 

AN/SPS-37A  260.0 

AN/SPS-5  2  2  3  0.0 

AN/SPS-40  240.0 

AN/SPS-3  9  2  9  0.0 

AN/SPY-1  300.0 


You  would  continue,  following  the  display  in  Figure 
3.115,  by  making  the  entry  shown  in  Figure  3.111. 
Following   the   display  of  the   air   search   radar  coverages,    you 
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would  have  the  opportunity  to  utilize  the  other  module 
features  of  changing  the  size  of  the  screen  display 
(Enlarge),  and  displaying  the  threat  sector  and/or  cartesian 
coordinate   axes.  These    topics   are    covered     in    succeeding 

sections.  Once  the  plot  is  as  you  desire,  you  will  be  afcle 
to  experiment  with  air  radar  coverages  by  moving  a  unit  and 
observing   the   resultant   change      in   coverage.  This    feature 

is   discussed  at    the    end   of    this   section. 

5 .      SENSOR    Modul e  zz  Display   of   Force   Fir  e  Control    Radar 
Coverages 

This  capability  of  the  SENSOR  module  allows  ycu  to 
display  the  coverage  areas  of  the  fire  control  radars 
installed      onboard  the      units   of      the      battle   group.  The 

display  would  show  the  units  in  the  force,  in  their  relative 
positions,    and    identified   by   name.  Around    each    unit    would 

te  a  circle  of  radius  scaled  to  the  respective  fire  control 
radar    installed    on      that   unit.  Table    IX      shows    the   ranges 

for    the    fire  control   radars    in   the   system. 

You  can  invoice  this  capability  from  the  query  shown  in 
Figure    3.112  by    making   the    following   entry. 

KE      --  DISPLAY    FCRADAR  <cr> 

VE     —      "Display"    "Fire   Control    Radars" 

In  addition  to  the  coverage  display  on  the  graphics  monitor, 
a  chart  of  the  units  and  their  respective  fire  control 
radars   would     be  displayed      on   the      terminal    screen.  The 

format   for    this    display  is_shown    in    Figure    3.116. 

As  ycu  can  see  from  the  information  displayed  in  Figure 
3.116,  the  name  of  the  unit  as  well  as  the  types  of  primary 
and    secondary   fire   control    systems,    as   applicable,      with  the 
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TABLE    IX 
DSS  Fire   Control  Radars 

Radar 

MK-91 

AN/SPG-55A 

AN/SPG-49 

AN/SPW-2 

MK-UO 

AN/SPG-51 

MK-7 

MK-76 

MK-74 

MK-56 

MK-99 

MK-68 

MK-92 

AN/SPG-53 

AN/SPG-60 

MK-13 

AN/SPQ-9 

AN/SPG-35 


Range 

(nm) 

12. 

0 

120. 

0 

100. 

0 

100. 

0 

80. 

0 

80. 

0 

40. 

0 

40. 

0 

40. 

0 

40. 

0 

40. 

0 

40. 

0 

40. 

0 

60. 

0 

50. 

0 

40. 

0 

20. 

0 

35. 

0 

*    BATTLE    GROUP    FIRE    CONTROL    RADARS    * 
UNIT    NAME  PRIMARY  SECONDARY 

***    PRESS    RETURN    TO    CONTINUE    *** 


RANGE 


Figure   3.  116        DISPLAY   —    Fire   Control   Radars. 

range   of     the  longest  range      system  are    shown.  After   the 

graphics  and  terminal  displays  are  complete,  you  can 
continue   by   making    the   entry      shown    in    Figure   3.111.  When 

you  continue,  ycu  will  have  the  opportunity  to  utilize  the 
ether  features  of  this  module,  enlarging  the  size  of  the 
graphics  plct,  and  displaying  the  threat  sector  and/or  the 
cartesian        coordinate      axes.  These      capabilities        are 
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discussed   in     succeeding  sections.  Once    the      substance   of 

the  plot  is  as  you  desire,  you  will  be  able  to  experiment 
with  the  coverage  areas  by  changing  the  position  of  a  unit 
and    observing      the    effect      on   coverage.  This    feature      is 

discussed    at  the   end   of  this   section. 

6  .      SENSOR    Module   —  Display   of   Force   Sonar   Co v er acje 

This  feature  of  the  SENSOR  module  allows  you  to 
display  the  coverage  areas  of  each  of  the  ship  mounted 
sonars    in  the   battle    group.  This   capability  will   show   the 

direct  path  range  for  all  force  sonar  systems. 
Additionally,  when  ycu  indicate  the  conditions  exist,  the 
display  will  include  the  convergence  zone  coverages  for 
those  equipments  which  are  capable  of  a  CZ  operating  mode. 
You  invoke  the  sonar  coverage  display  by  making  the 
following    response    to   the  query   shown    in    Figure    3.112. 

KB      —  DISPLAY    SONAR  <cr> 

VR      —      "Display"    "Sonar   Systems" 

Once  you  designate  that  you  desire  to  see  the  sonar  cover- 
ages, you  will  next  te  queried  on  the  existance  of  conver- 
gence zcre  conditions.  This  query  is  shown  in  Figure3.117, 
and   the    desired    response   is    a   YES/NO   answer. 


r 


???    DO    CONVERGENCE     ZONE    CONDITIONS    EXIST    ??? 
(YES    CR    NO) 


Figure   3-117        Query   —    Existance   of   Convergence   Zone. 
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Should  ycu  make  an  error  in  entering  the  YES/NO  response, 
you  would  see  the  following  on  the  screen,  after  which  you 
can    reenter   your  YES/NO   response. 

PLEASE    ENTEB    "YES"    OR    "NO." 

Bememfcer,      EO   NOT   enter  the      quotes.  If    you  indicate   that 

convergence  zone  conditions  exist,  those  sonars  which  are  CZ 
capable  will  be  flagged  to  show  a  30  nautical  mile  annulus 
en  the  graphics  monitor.  The  overall  display  will  show  the 
units  in  the  battle  group  in  their  relative  positions,  and 
identified  by  name.  Surrounding  each  unit  will  be  first,  a 
"cyan"  circle  representing  the  CZ  annulus  (if  the  unit  has  a 
CZ  capable  sonar,  AKD  you  indicate  the  conditions  exist), 
and  a  "green"  circle  scaled  to  the  direct  path  range  of  the 
sonar  onboard  that  urit.  Table  X  shows  the  DSS  sonars  with 
their   direct  path   ranges  and  their    CZ    capability. 


T1BLE    X 
DSS  Sonar   Systems 

Sonar  DP   Range    (nm)  CZ    Capable 

No 
NO 
Yes 

No 

No 
Yes 

No" 
Y«c 

No 

Yes 

Yes 


AN/EQQ-5 

Passive 

AN/EQS-15 

3.0 

AN/BQQ-2 

6.0 

AN/EQS-6 

3.0 

AN/EQR-7 

Passive 

AN/EQS-12 

3.0 

AN/SQS-23 

2.0 

AN/SQS-26 

4.0 

AN/SQQ-23 

Passive 

AN/SQS-53 

U.O 

AN/SQS-56 

3.0 
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In  addition  to  the  display  of  the  coverage  areas  on  the 
graphics  monitor,  a  summary  of  the  sonars  in  the  battle 
group,  with  respect  to  unit  capabilities,  is  presented  on 
the   terminal  screen.  The    format   for   this  display   is    shewn 

in   Figure   3.118. 


*    BATTLE    GRO0P    SONAR    SYSTEMS    * 
UNIT    NAME  SONAR  RANGE 

*    **    PRESS    RETURN    TO    CONTINUE    *** 


Figure   3.118        DISPLAY  —   Battle    Group   Sonar   Systems. 

You  would  continue  by  entering  "RETURN"  as  shown  in 
Figure    3.111.  When   you   continue,    you    will   have    the    oppor- 

tunity to  utilize  the  other  features  of  this  module, 
enlarging  the  size  of  the  plot,  displaying  the  threat  sector 
and/or  cartesian   coordinate    axes.  The    functions   of   these 

features   are      discussed   in    succeeding   sections.  Once   the 

plot  is  as  you  desire,  you  will  have  the  opportunity  tc 
experiment  with  the  sonar  coverages  by  changing  the  posi- 
tion (s)  of  up  to  ten  units  and  observing  the  effects  on 
coverage.  These      procedures    are   discussed     at    the      end   of 

this    section. 

7  •      Incorporation  of   AE  W    Radar    Co v er a^ es 

Once  the  organic  sensor  assets  of  the  battle  group 
have  been  displayed,  regardless  of  the  capability  (air, 
surface,  etc.)  ,  you  will  be  offered  the  opportunity  to 
display  the  coverage  area  of  either  an  E-3A  or  E-2C  AEW 
aircraft.  Within      this    feature,      you      will  also      have   the 

ability   tc   input  a    specific    coverage   range    for  the 
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respective    radar  onbcard  the      selected   aircraft,      or    utilize 
the    system      default    range.  The   format      for  the      query  to 

invoke    this   feature    is   shown   in    Figure   3.119. 


YCD    HAVE    THE    OPTION    OF    PLACING    AN    "AWACS"    OR    A 
"HAWKEYE"    ON    STATION. 

???    WOULD    YOU    LIKE    TO    DO    THIS    ??? 

(YES    CR    NO) 


Figure   3. 119        Query  —  Utilization   of   an   AEW   Aircraft. 


If  you  indicate  that  you  desire  to  place  the  aircraft  on 
station,  and  enter  "YES,"  you  will  next  be  asked  which  type 
cf   aircraft      you  desire  to      utilize.  The   format      for  this 

query    is   shewn    in  Figure   3.  120. 


???    WHICH     AIRCRAFT    WOULD    YOU    LIKE    TO    POSITION    ??? 

1  --       E-3A       SENTRY        (AWACS) 

2  —      E-2C       HAWKEYE 

(ENTEB    1    or    2) 


Figure   3.120        Query   —   Determination   of   Type  of    AEW   Aircraft 


The  format  of  the  desired  response  is  straightf oward. 
Should  an  error  occur  in  making  this  response,  you  will  be 
asked  tc  reenter  your  selection.  The  next  queries  you  will 
be    presented   with  address   the   range   of    the    radar    onboard   the 
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aircraft   you     select.  The  respective   query      sequences   are 

covered    in    the   next    two   sections. 

a.      Determination   of    E-3A   Radar    Range 

If  ycu  s€lected  the  E-3  A  aircraft  in  response  to 
the  query  shown  in  Figure  3.120,  you  will  be  asked  if  you 
desire  tc  utilize  the  system  default  range  for  the  AN/APY-1, 
or  input  ycur  own  ranee.  The  format  of  this  qu<=ry  is  shewn 
in   Figure    3.121. 


THE    AN/APY-1     RADAR    ONBOARD    THE    E-3A    AIRCRAFT    HAS    EEEN 
GIVEN    A    SYSTEM    RANGE    OF     350    NM.       YOU    HAVE    THE    OPTION 
OF    ENTERING     YCUR    CKN    RANGE    IF    YOU    DESIRE.  IF    YOU 

DESIRE    TO    USE   THE    SYSTEM    RANGE,    PRESS    "CARRIAGE    RE- 
TURN,"   OTHERWISE,    ENTER    THE    RANGE    YOU    DESIRE. 

(LIMITS    1    -    500    NH). 


Figure  3.121         Determination  of   AN/APY-1   Range. 


If      ycu     desire      to      use  the      system      range,        simply      enter 
"RET0BN,"   as  shown    in   Figure    3.111.  If    you   desire   to   use 

your    own   range,         for   example,      200    nm,      you      would    make   the 
following  entry. 

KE      —  200  <cr> 

VF      —      "Two"    "Zero"    "Zero"    "Carriage   Return" 

b.      Determination   of    E-2C   Radar    Range 

If  you  selected  the  E-2C  aircraft  in  response  to 
the  query  shown  in  Figure  3.120,  you  will  be  ask°d  if  you 
desire  tc  use  the  system  default  range  for  the  AN/APS-125. 
The    format    of  the  query    is    shewn    in   Figure    3.122. 
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THE  AN/APS-125  RADAR  ONBOARD  THE  E-2C  AIRCRAFT  HAS 
EEEN  GIVEN   A  SYSTEM  RANGE  OF  250  NM.   YOU  HAVE  THE 
OPTION  OE  ENTERING  YDR  OWN  RANGE  IF  YOUR  DESIRE.   IF 
YOU  DESIRE  TO  USE  THE  SYSTEM  RANGE,  PRESS  "CARRIAGE 
RETUBN,"  OTHERWISE,  ENTER  RANGE  YO 0  DESIRE. 

(LIMITS  1  -  500  NM)  . 


Figure   3.122        Determination  of   AN/APS-125    Range. 


The    format    for      the    desired    response   to   this      query   is    iden- 
tical  to  that   of  entering  the   AN/APY-1    range. 

c.      Determination   of   AEW    Station 

Once  the  AEW  aircraft  has  been  identified,  you 
will  next  be  asked  to  enter  the  position  of  its  station. 
The  format  for  this  entry  is  different  from  the  bearing/ 
range    input    you    made    for  the      ships.  For   this    input,      the 

tearing/range  entry    will     be   made   as   one      response,      and   the 
range    will    be   entered  in      nautical   miles.  The    formats   for 

the    position     query   and     the   desirad      response  are      shown   in 
Figures    2.123   and   3.124,    respectively. 


???    WHAT    IS    THE    BEARING     AND    RANGE    OF    THE    AEW    STATION 
FEOM    ZZ     ??? 

(ENTER    AS    "BBB    RRR"    WITH    BEARING    IN    DEGREES   TRUE,    AND 
RANGE    IN    NAUTICAL    MILES.  E.G.     BEARING    330     RANGE 

200    NM    WOULD    EE    ENTERED    AS:       330    200) 


Figure    3.123        Determination   of   Position   of   AEW    Station. 
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If  you  desired  to  place  the  AEW  aircraft  at  a  station 
bearing  225  degrees  true,  150  nautical  mil<=>s  from  ZZ. 
ycu  would  make  the  following  entry.  (The  voice  format 
is   soirewhat    cumbersome!) 

KB   --  225  150  <cr> 

VR      —      "Two"    "Two"   "Five"    "Space"    "One"   "Five" 
"Zero"    "Carriage   Return" 


Figure   3« 124        Voice/Keyboard    Response    for    AEW    Station. 

Once    the  position  of   the  AEW      station    has  been  entered,      the 

applicable   coverage   of  the    onboard      radar  will  be    displayed, 

and  ycu  will  be  cycled  to  the  option  to  enlarge  the  view, 
the   next   topic. 

8 .      Enlarging    the   Size    of   the   Graphics    Display 

Cnce  the  display  of  the  desired  SENSOR  module 
feature  has  been  completed,  ycu  will  be  queried  as  to 
whether    you  desire    tc   ENLARGE   the      size    of   the  plot.  When 

the  graphics  plot  is  initially  established,  the  dimensions 
cf    the    screen   are    1000  nm   by    950    nm .  In    some    cases,      this 

scale  is  toe  large  tc  accurately  view  the  information  repre- 
sented. This  is  particularly  true  when  displaying  posi- 
tions, cr  short  range  radar  or  sonar  capabilities.  To 
allow  you  the  opportunity  to  vary  the  scale  of  the  plot  to 
meet  ycur  needs,  you  will  have  the  option  of  ENLARGING  the 
display.  The  query  addressing  this  feature  is  shown  in 
Figure   3.125. 

The    desired     response   to     this    query      is   YES      or    NO.  The 

formats  for  these  response  options  are  presented  again,  as  a 
refresher.  Should      an   error      occur   in      making    the      YES/NO 

response,  the  following  will  appear,  after  which  you  can 
reenter    the   response. 
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???    WOULD    YOD    II KE    TO    ENLARGE    THIS    VIEW    ??? 
(YES    CE    NO) 


Figure    3.125        Query   —    Enlarge   the   View. 

PLEASE    ENTEB    "YES"    OR    "NO" 

Rememfcer   not      to   enter  the      quotes!  Hare   are      the   correct 

response   formats. 

KE      —  YES        <cr>  or  NO        <cr> 

VE      —      "Affirmative"  or  "Negative" 

If  you  indicate  you  do  not  desire  to  enlarge  the  plot,  you 
will      continue    to      the   next      module    feature.  If    you      do, 

however,  desire  to  enlarge  the  plot,  the  query  shewn  in 
Figure  3.126,  addressing  the  number  magnifications  you  want 
applied   to    the    plot,    will  be    presented. 


???    EY    HOW    MANY    TIMES    WOULD    YOU    LIKE    TO    ENLARGE    THE 
PICTURE     ??? 

(ENTEB    THE    DESIRED    NUMBER     (RANGE    2-5)) 


Figure   3. 126        Query    —   A«ount    of    Enlargement. 


This  query  will  appear  only  once,  meaning  you  can  only 
change  the  scale  cne  time  with  each  sensor  capability 
display.        If   the  new   scale    is   not   the    plot   size    you    desire, 
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you  would  have  to  return  to  the  module  menu  (continue 
through  the  end  of  the  sequence)  ,  and  reinitiate  the  display 
cf  the  capability.  The  desired  response  to  the  query  shewn 
in  Figure  3.126  is  the  number  corresponding  to  the  relative 
increase  in  the  plot  size  you  prefer.  If,  for  example,  you 
desired  to  enlarge  the  plot  four  (4)  times,  you  would  make 
the    fcllcwirg  entry. 

KB      —  4  <cr> 

VR      —      "Four"   "Carriage   Return" 

This  would  cause  the  plot  to  be  redisplayed  at  a  scale  four 
times   the   initial  view  size.  The      pict   would   now   have   the 

dimensions   of      250    nm  by     237    nm .  The      coverage    currently 

being  displayed,  as  well  as  any  follow  on  feature,  will 
maintain   this  new   scale. 

The  system    will   check   your      response    to    the   query   in 
Figure      3.126   against     the      allowable      range   for      the      entry 
(2-5)  .  If     your    response    is      not    within    this      range,      the 

statement    shown    in    Figure    3.127   will    be    shown. 


PHASE    RESTRICT    YOUR    ENTRY    TO    THE    RANGE    2-5. 


Figare    3.127        ERROR   —   Enlargement   Scale    Not   Within   Limits. 


Should   an  error      occur,      after    the   warning,        simply    reenter 
your    response   for  the  amount   of   enlargement    (2-5    times) . 
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9  •      Displaying        the 
Coordinate   Axes 


Threa- 


Sector 


and 


Cartesian 


Cnce  the  size  of  the  display  is  set,  and  ycu  are 
satisfied  with  the  scale  of  the  plot,  you  will  next  have  the 
opportunity  to  display  the  cartesian  coordinate  axes  and/or 
display   cr    modify      the  threat   sector.  The      query    shown   in 

Figure   3.128  addresses  these   capabilities. 


???    WCULD    YOU    LIKE   TO   SEE    EITHER    OF   THE    FOLLOWING    ??? 

1  —    VERTICAL    PLOT    AXES 

2  —    THREAT    SECTOR 

(ENTER    THE    APPROPEIATE    NUMBER    OR    PRESS    "CARRIAGE    RE- 
TURN"   TO    CONTINUE) 


Figure    3.128        Query  —  Threat   Sector/Vertical    Plot    Axes. 

You  will  cycle  to  this  or  the  query  shown  in  Figure 
3.129,  each  time  you  make  a  change  to  the  plot  by  moving  a 
unit     (discussed    later).  If   an   error   occurs  in    making   this 

response,  the  warning  shown  in  Figure  3.113  will  be 
presented,    after   which   you    can    reenter   your   response.  If, 

through  the  course  of  experimenting  with  coverages,  you  have 
already  displayed  the  VERTICAL  PLOT  AXES,  you  would  then 
only  te  asked  if  you  desire  to  display,  or  if  it  is  already 
displayed,  redefine  the  THREAT  SECTOR.  This  query  is  shown 
in    Figure    3.129. 

The  desired  response  to  the  query  shown  in  Figure  3.128  is 
the    YES/NO    entry   which   has    been   discussed    before.  If,    you 

do  net  desire  to  display  either  of  these  features,  ycu  would 
simply  enter  "RETURN"  as  shown  in  Figure  3.111,  and  you  will 
cycle   to   the  next    module   feature,      changing   the    positions   of 
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(       ???    SCOLD    YOO    LIKE   TO    DISPLAY    OR    REDEFINE    THE    THREAT 
j  SECTOR    ??? 

I        (YES    CR    NO) 


Figure   3.  129        Query  —  Display/Redefine   Threat   Sector. 

the    units.  This      feature    is    discussed   at   the      end   of   this 

section.  Let*s      first      look   at      each      of     these      display 

features  (threat  sector/cartesian  grid)  and  their  query 
sequences   individually. 

a.      Display    cf  the    Cartesian   Coordinate   Grid 

If  you  desired  to  display  the  cartesian  coordi- 
nate grid  (VERTICAL  ELOT  AXES) ,  you  would  make  the  following 
entry   in   response   to    the  query   shown    in    Figure  3.128. 

KB     --  1  <cr> 

VR      --      "One"    "Carriage   Return" 

This  response  will  immediately  cause  the  graphics  monitor 
display  to  te  refreshed,  this  time  displaying  the  cartesian 
grid,  scaled  to  your  enlarged  plot,  if  applicable,  along 
with    the   capability      coverage   you  are    viewing.  Until    you 

erase  the  graphics  monitor  view  (return  to  the  module  menu) , 
the  grid  will  be  continuously  displayed.  Once  the  grid  has 
teen  displayed,  you  will  be  given  the  query  shown  in  Figure 
3.129,  tc  provide  ycu  the  opportunity  to  display  the  threat 
sector.  We  will      new    look   at    the      sequences   involved    with 

the    display   of    the    threat  sector. 

t.      Display    cf  Threat    Sector 

You  would  cause  the  threat  sector  to  be 
displayed   by  making   the   appropriate      response   to    the   queries 
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shown   in      Figure   3.128,      or      Figure    3.129.  There      are   two 

different      query      sequences      which   follow      the     response     to 
display   the   sector.  These   sequences      are    keyed    to   whether 

the    sector   is      already  being   displayed.  If     the   sector   is 

already    displayed,    then   you    will   be   given   the   opportunity   of 
redefining    the    sector.        We    will   look    at   both   cases. 

H )      Thy § at     Sector      Initial   Display.  If      the 

threat   sector  has   as   yet  not   been   displayed,    the    first    guery 
you    will   see  is    shown   in  Figure   3.130. 


???     WHAT    IS    THE    THBEAT    BEARING    ??? 
(ENTER    EEARING    IN    DEGREES     (0    -    359)) 


Figure  3.130         Query    —   Defining   Threat   Bearing. 


If  the  force  faced  a  threat  from  a  bearing  of  300  degrees 
true,  the  following  entry  would  be  made  in  response  to  the 
query   shewn   in    Figure   3.130. 

KB      —  300  <cr> 

VR      —     "Three"   "Zero"    "Zero"    "Carriage   Return" 

The  system  will  check  the  entry  to  ensure  it  is  within  the 
authorized  limits  (0  -  359),  and  should  it  not  be  within 
those  limits,  the  following  warning  will  appear,  after  which 
you   can    reenter    your   threat    bearing. 

lOUR  ENTBI  HAS  NOT  BEEN  ACCEPTED.  PLEASE  REENTER  THE  THREAT 
EEARING    IN    DEGREES     (0   -    359)  . 

Once  the  threat  bearing  has  been  determined,  you  will  next 
be  asked  for  the  width  of  the  threat  sector.  This  query  is 
shown    in   Figure    3.13  1. 
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???    WHAT    IS    THE    THREAT    SECTOR    WIDTH    ??? 
(ENTER    IN   DEGREES     (0    -    360)) 


Figure    3,131        Query  —  Threat   Sector   Width. 


As  an  example,  if  the  threat  sector  is  90  degrees  wide,  the 
following  wculd  be  the  correct  entry  in  response  to  this 
query. 

KB      —  90  <cr> 

VR     --   "Nine"   "Zero"    "Carriage   Return" 

If  a  mistake  were  to  occur  when  making  this  response,  the 
following  warning  would  appear,  after  which  you  could 
reenter   the  threat    sector   width. 

YOUR  ENTRY  HAS  NOT  BEEN  ACCEPTED.  PLEASE  REENTER  THE  THREAT 
SECTOR    WIDTH    IN    DEGREES     (0     -    360)) 

Onc€  the  threat  bearing  and  sector  width 
have  been  correctly  input,  the  graphics  monitor  will  now 
redisplay  all  the  current  information,  plus  the  threat 
sector.  The    sector   will    be    marked   in    red,    centered   on   the 

threat      tearing,      and     originates  at      "ZZ."  Now   that      the 

threat  sector  has  been  displayed,  each  time  you  cycle 
through  the  query  shown  in  Figure  3.129,  you  will  have  the 
cpportunity  to  redefine  the  existing  sector,  if  you  so 
desire.        This    is   the  topic    of   the   next   section. 

(2)       Redefining      the      Threat      Sector.  If      you 

desired  to  redefine  an  already  existing  threat  sector,  you 
would  enter  "YES"  to  the  query  shown  in  Figure  3.129.  This 
response   will      result   in      the    query      shown    in      Figure    3.132, 
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presenting  the  parameters  cf  the  existing  sector  to  ycu. 
As  shewn,  the  query  reflects  the  sector  parameters  which 
were  used  in  the  previous  example. 


I  I 

|   TEE  TEREAT  SECTOR  IS  CURRENTLY   90  DEGREES  WIDE,  CEN-    \ 
TEREE  ON  A  BEARING  OF  30  0  DEGREES  TRUE.  ! 

|  ???  IS  THIS  STILL  CORRECT  ???  I 

I 
j        (YES    CR    NO)  I 

i i 

Figure   3.132        Description   of   Existing   Threat    Sector. 


The    desired   response      is  YES   or   NO.  If      you  indicate  that 

the  current  sector  is  correct,  by  entering  YES,  you  will 
continue  to  the  module  feature  where  you  can  experiment  with 
unit    positions.  If   you   would      like    to   change/redefine   the 

sector,  and  enter  NC,  you  will  repeat  the  query  sequences 
starting  with  that  shewn  in  Figure  3.130,  and  discussed 
above.  Should      an      error    occur      in      making      the      YES/NO 

response,   ycu  would    be   asked   to   reenter   the   response. 

10.    Experimenting   with    Moving  a    Unit 

A   significant   feature  of  the   computer    graphics   capa- 
bilities  of   this  DSS    is   allowing   the   user   to    experiment   with 
the    effect    en      sensor    (or   weapons  systam,        discussed   later) 
coverage   cf   moving    a    unit.  To   afford   you   the    opportunity 

to  redeploy  the  forces  of  the  battle  group,  in  order  to  best 
grasp  the  optimum  overall  coverage  effectiveness,  this  DSS 
feature  allows  you  to  move  up  to  ten  (10)  units.  (The  limit 
of  1 0  was  determined  based  on  the  amount  of  clutter  on  the 
graphics  monitor      when   an      inordinate    number     of    ships      were 
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moved,  thereby  displaying  both  their  old  and  new  positions, 
and   coverages.)  Each     of    these   ten   units   can      be    mov=d   an 

indefinite   number  of   times,      however.  Unfortunately,      the 

ESS  has  not  been  designed  to  allow  you  to  move  the  AEW 
aircraft,      once      they  are  in      place.  This    change      in   unit 

position  is  not  to  he  confused  with  the  changing  of  posi- 
tions in  the  STATUS  module.  The  position  change  in  this 
module  is  temporary  and  will  not  be  made  permanent,  as  you 
will  see.  The  query  utilized  to  invoke  this  feature  is 
shown    in   Figure    2.133. 


j  ???    DO    YOU    DESIRE   TO    EXPE5IMENT    WITH    COVERAGES    BY 

|  MOVING    A    UNIT    ??? 

I 

(YES    CR    NO) 

)        (YCU    CAN    INDIVIDUAILY    MOVE    UP    TO    TEN     (10)     UNITS.) 


L 


Figure   3.  133        Query  —   Move   a   Battle   Group    Unit. 


The  desired  response  to  this  query  is  "YES"  or  "NO,"  the 
format   for      which   you  have      seen    before.  If      you    indicate 

that  you  desire  to  mcve  a  unit,  and  enter  "YES,"  the  first 
query  you  will  see  is  to  identify  the  unit  you  desire  to 
move.  The  format  of  this  query,  with  a  representative  ship 
names,   is   shown    in    Figure   3.13  4. 

If  an  error  occurs  when  making  this  response,  or  the  name 
entered  cannot  be  matched  to  the  names  of  the  battle  group 
units,  ycu  will  be  asked  to  reenter  the  name  of  the  unit  you 
desire  to    mcve.  Once  the    unit      to  be    moved   is    identified, 

you    wculd   next      be    asked   for  the   new    position     of   that    unit. 
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??    WHAT    IS    THE    NAM5    OF    THE    UNIT    YOU    DESIRE   TO    MOVE    ?? 
CAEL    VINSON  PAUL     F    FOSTER  CALIFORNIA 


Figure   3.134        Query   —    Name  of  the   Onit  to  be   Hoved. 

The  format  of  this  query  is  based  on  the  type  of  coordinate 
system    (polar      or   cartesian)       in   use.  The    query/response 

sequences,  however,  are  identical  to  those  used  in  the  BUILD 
module.  If  you   are  using    the   polar   coordinate    system,    you 

will  be  asked  for  the  bearing  and  range  of  the  ship*s  new 
position  frcm  "ZZ."  If  you  are  using  the  cartesian  system, 
you  will  be  asked  for  the  quadrant,  x  and  y  positions  of  the 
unit.  Since    these      sequences   are  ones   with      which   ycu   are 

already    familiar,      they   will   net    be   repeated   here.  If   you 

need  to  review  their  formats,  you  should  refer  to  the  appro- 
priate section  of  the  BUILD  module.  Remember,  the  new 
position  is  of  a  temporary  nature  until  you  state  otherwise. 
When  the  new  position  of  the  unit  has  been  entered, 
the  display  on  the  screen  will  be  repeated,  this  time, 
showing  the  new  as  well  as  the  current  system  position  for 
the  unit  ycu  moved.  This  contrasting  display  will  give  you 
a  feel  fcr  the  dynamics  of  the  change  you  made.  Once  the 
new  display  has  been  presented,  you  will  be  asked  if  you 
desire  this  NEW  position  be  made  permanent.  The  format  for 
this    query    is   shown    in    Figure    3.135. 

The  desired  response  to  this  query  is  "YES"  or  "NO,"  the 
format   of   which      we    have   discussed   before.  If      ycu   do   not 

want  this  position  change  to  be  made  permanent,  enter  "NO," 
and  ycu  will  cycle  tc  the  query  regarding  the  display  of  the 
threat   sector  or  cartesian    grid,      as   appropriate.  For  the 
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???    DO    YOU    WANT    THIS   CHANGS    TO    BE    MADE    PERMANENT    ??? 
(YES    CR    NO) 


Figure   3.135        Query  —  Hew  Position  to  be  Made    Permanent. 

remainder  of  the  capability  display,  however,  the  new  posi- 
tion cf  the  unit  will  be  displayed  along  with  the  current 
system   pcsition.  Ycu   can    change   the    position   of    up    to   ten 

(10)       units.  You    can   also   come      back   to    any  unit    and   make 

another    position  chance    if    you   desire.  When  you   nc   lcnger 

indicate  that  you  desire  to  change  the  position  of  a  unit, 
you  will  complete  the  full  display  capability  of  this 
module,  and  you  will  he  advised  that  the  displayed  graphics 
will  be  erased  when  you  continue.  This  warning  is  shown  in 
Figure    3.136. 


**    CADTION    **       THE    DISPLAYED    GRAPHICS    WILL    EE 

ERASEE    WHEN    YOU    CONTINUE 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure   3.136        WARSIHG   —    Erasure   of   Displayed   Graphics. 


You  would  continue  by  entering  "RETURN"  as  shown  in  Figure 
3.111,  and  you  will  he  returned  to  the  module  menu  (Figure 
3.112)  . 
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K.       153FCNS    MODULE    OPEBATIONS 

The  functioning  cf  the  WEAPONS  module  is  oriented  to 
computer  graphics  displays  of  the  capabilities  of  the  battle 
group    weapons.  The  purpose   cf   this   module    is  to   allow   you 

to   display   the    force    weapons   capabilities    in    AAW ,      ASW,      and 
ASUW.  You  would    invoke  the      WEAPONS    module   from    the   query 

shown    in    Figure    3.6.        The    format   for   this   response    is    shewn 
in   the   fcllcwing   example. 


KB 


WEAPONS 


<cr> 


VR      —      "Weapons    Module" 

The  initial  view  which  ycu  observe  upon  invoking  this  module 
is  shewn  in  Figure  3.137  (adjusted)  .  The  information  shown 
discusses   the      capabilities    of      the   module.  This   display 

will  enly  cccur  after  the  first  invocation  of  the  module. 
You  can  continue  by  entering  "RETURN,"  as  shown  in  Figure 
3.138. 


*    BATTLE    GROUP    ASSET    MANAGEMENT    * 
DECISION    SUFFORT    SYSTEM 

*    WEAPONS    MODULE* 

THIS    MODULE    WILL    AILOW    YCU    TO    DISPLAY    THE    FORCE    WEA- 
PONS   EFEECTIVENESS    AREAS.       YOU    WILL    BE    ABLE    TO    DISPLAY 
MISSIIE,    GUN,    AND    ASW    WEAFCNS    SYSTEMS,     AS    WELL    AS 
TCMAHAWK    AND     HARPCON    EFFECTIVENESS    AREAS.  AS    WITH 

THE    SENSCR    MODULE.    YOU    WILL    EE    ABLE    TO    DISPLAY    THE 
CARTESIAN    AXES,     TEE    THREAT    SECTOR,     AND    EXPERIMENT    WITH 
EFEECTIVENESS    BY    KCVING     A    UNIT    AND    OBSERVING    THE    RE- 
SULTANT   EFFECT. 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure    3.13*7        WEAPONS   Module   Description. 
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KB 
VR 


<cr> 

"Carriage   Return" 


Figure   3.138        Entry   of    "CAHHIAGE    RETURN"    or    "RETURN". 

After  you  continue,  the  next  display  will  be  the  one  which 
will    serve    as  the   major  menu   for   the   module.  The    composi- 

tion of  this  menu,  which  also  functions  as  a  query,  is  shewn 
in  Figur?  3.139.  This  menu  is  a  straightfoward  explanation 
of   the   categories  of   the  displays  available. 


*    WEAPONS     MODULE    OPTIONS    * 


MISSILE 

GUN 

MSLGDN 

ASW 

TOMAHAWK 

HARECON 

TCMHAR 

EXIT 


DISEIAY 
DISPLAY 
DISPLAY 
DISPLAY 
DIStlAY 
DISPLAY 
DISEIAY 
WEAPONS 
RETUFN 


FOBCE 
FORCE 
FORCE 
FO  BCE 
FORCE 
FORCE 
FORCE 
SYSTEMS 
TO    THE    MAIN 


MISSILE    SYSTEMS 

GDN    SYSTEMS 

MISSILE    AND    GUN    SYSTEMS 

ASW    WEAPONS    SYSTEMS 

TOMAHAWK    WEAPONS    SYSTEMS 

HARPOON    WEAPONS    SYSTEMS 

TOMAHAWK     AND    HARPOON 


MODULE 


???    WHAT    IS    YOUR     SELECTION    ??? 


Figure   3.139        WEAPONS   Module   Options. 


The   desired   response   to   this   query   is   the   name  of   the   option 
you    desire.  Should  a    keyboard      error    occur   in    making   this 

reponse,    the  following   warning   will    be   displayed. 

YOUR    SELECTION    WAS    NCT    ACCEPTED    BY    THE    PROGRAM,     AND    YOU    WILL 
HAVE    TO    REENTER 
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Once  you  have  made  ycur  selection,  the  system  will  attempt 
to  match  your  response  to  one  of  the  options  available.  If 
no  match  is  made,  then  the  warning  shown  in  Figure  3.  140 
will    te    displayed. 


YCCR    RESPONSE    IS     KCT    RECCGNIZEA3LE    AS    BEING    FROM    THE 
AVAILABLE   OPTIONS 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure   3.140        ERROR   -   Ho   Hatch   of   Input   To   Available   Options 


You  can  continue  by  entering  EETORN,  as  shown  in  Figure 
3.138.  When    y  cu    ccntinue,      the   module    menu    (Figure    3.139) 

will  again  be  displayed  and  you  can  reenter  your  response. 
Identical  tc  the  capabilities  cf  the  SENSOR  module,  this 
module   also     allows    ycu     several   special      features.  These 

features  include  enlarging  the  size  of  the  plot,  display  of 
the  cartesian  axes,  display  of  a  threat  sector,  and  experi- 
mentally mcving  a  unit  and  observing  the  effects  the  move 
has    on      weapons'    coverage.  You      will   also   have      the    capa- 

bility of  imposing  a  CAP  station  on  top  of  the  ship  system 
coverages.  The   pragmatics   involved    with    responding   to   the 

queries  associated  with  these  special  features  have  already 
been  discussed  in  the  SENSOR  module  operations  section,  and 
will    not      be  discussed      here.  The      points    at      which    these 

features  may  be  invoked  in  the  WEAPONS  module  will,  however, 
be    emphasized.  Additionally,      as      you   have      seen    in      the 

SENSOR  mcdule,  in  most  cases,  the  graphics  displays  will  be 
paralleled  with  a  capabilities  display  on  the  terminal 
screen.  The    results     of    selecting    aach   of     the   available 
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WEAPONS  nodule  options  will  be  discussed  in  the  following 
topics   of  this    section. 

1 •      Display    of    Available   Options 

In  ^he  succeeding  sections,  we  will  discuss  the 
sequences  involved  with  the  various  display  options  in  this 
module.  Following     the      explanation      of      the      individual 

options,  the  sequences  associated  with  enlarging  the  plot, 
stationing  a  CAP,  and  the  display  of  the  cartesian  axes  and 
threat  sector  are  discussed  with  respect  to  the  queries  you 
will    see   to   initiate   them.  For   a   detailed  explanation  of 

the  functioning  of  each  of  these  features,  you  should  refer 
to  the  appropriate  section  in  SENSOR  MODULE  OPERATIONS. 
The  rationale  for  changing  the  scale  would  be  that  in  seme 
displays,  the  coverage  areas  of  the  capability  selected 
could  be  seen  in  more  detail  when  the  scale  is  changed. 
The  initial  size  of  the  graphics  plo-  is  1000  by  950 
nautical   miles.  You   will    be    able   to   change  this    size  to   a 

minimum  of  200  by  190  nautical  miles,  if  you  so  desire, 
lor  a  review  of  the  operations  of  this  feature,  again,  you 
should  refer  to  the  appropriate  section  within  SENSOR  MODULE 
OPERATIONS.  Now    we      will    look      at      the    various      WEAPONS 

module   options. 

a.      Display    cf   Force-  Missile    System   Coverage    Areas 

If  you  desired  to  display  the  coverage  areas  of 
the  force  missile  systems,  then  your  response  would  te  as 
shown    below. 

KB       —  MISSILE  <cr> 

VR      —      "Guided    Missile   Systems" 

The  result  cf  this  entry  would  be  a  display  on  the  graphics 
monitcr  cf  the  battle  group  units  in  their  relative  posi- 
tions,   identified   by    name,    and   as  applicable,      surrounded   by 
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a  circle   scaled    to    tie   capability   of   their   installed   missile 
system.  The    DSS    ranges   for   individual   missile    systems   are 

shown   in   Table   XI. 


TABLE  XI 
DSS    aissile   Systea   Ranges 

Missile  System  Range    (nm) 

NSSMS     (FIM-7)  7.0 

SM1-ER     (RIM-67)  40.0 

EPCMS     (RIM-"7)  6.5 

SM2-MR     (RIH-66C)  50.0 

SM1-MR     (RIM66B)  25.0 

SM2-ER     (RIM-67B)  90.0 


On  the  terminal  screen  would  be  a  summary  of  the  force 
systems,  identified  by  ship  name,  primary  system  type, 
secondary   system  type,    and    longest   operational  range.  The 

format    fcr    the    terminal    display   is    shown    in   Figure    3.141. 


*    BATTIE    GROUE    MISSILE    SYSTEMS    * 

UNIT    NAME         PRIMABY    SYSTEM         SECONDARY    SYSTEM  RANGE 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure   3.14  1        Terminal   Display   -   Battle   Group  Missile    Sys. 
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Cnce  the  missile  system  capabilities  have  been  displayed, 
ycu  will  be  able  to  change  the  scale  of  the  plot,  or  display 
the  threat  sector  and  cartesian  coordinate  axes,  as  well  as 
experiment  with  changing  a  unit's  position.  The  queries  to 
initiate   these    features   are    shown   in    succeeding   sections. 

b.      Display    cf  Force  Gun   Weapons  System   Coverages 

If  you  desired  to  display  the  force  gun  weapons 
system  coverage  areas,  you  would  make  the  following  response 
to   the   query  shown    ir.  Figure   3.139. 

KE      —  GUN         <cr> 

VE      —         "Gun    Systems" 

As  a  result  of  this  input,  you  would  see  a  display  on  the 
graphics  mcnitcr  of  all  the  battle  group  units  in  their 
relative   positions,    and   identified   by    name.  Additionally, 

you  wculd  see  in  the  display,  a  circle  cf  radius  scaled  to 
the  onboard  gun  system  capability,  surrounding  each  unit. 
Table  XII  shows  the  DSS  ranges  for  the  available  gun  weapons 
systems. 


TABLE   XII 
DSS   Gun    Systea  Ranges 

Gun  System 

16"/50     f406    mm)     MK7     MOD    0 

5"/38    (127    mm)     MK12    MOD    1 

2mm/70    MK4 

5"/5U    (127    mm)    MK42 

5"/54    (127    mm)     MKU5 

3"/50     (76    mm)    MK22 

"76    mm  (OTO    MELARA) 


Range 

(nm) 

20. 

0 

10. 

0 

3. 

,0 

13. 

0 

13. 

.0 

10. 

.0 

8. 

.0 

« 
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Cn  the  terminal  screen  would  be  displayed  the  gun  capabili- 
ties by  ship  name,  cun  system  installed,  and  gun  range. 
The  fcrmat  for  this  presentation  is  shown  in  Figure  3.142. 


*  BATTLE  GROUP  GUN  SYSTEMS  * 

UNIT  NAME  SYSTEM  RANGE 

***  PRESS  RETURN  TO  CONTINUE  *** 


Figure  3. 142   Battle  Group  Gun  Systems. 


Once  the  gun  ranges  are  dislayed,  you  will  be  able  to  change 
the  scale  of  the  plot,  and  display  the  threat  sector  and 
cartesian  coordinate  axes,  as  well  as  experiment  with 
changing  a  uni t • s  position.  The  queries  to  initiate  these 
features  are  shown  below. 

c.   Display  of  Force  Missile  and  Gun  Weapons  Systems 

If  you  desire  to  display  the  force  coverage 
areas  with  respect  to  BOTH  missile  and  gun  systems 
installed,  then  you  would  enter  the  following  in  rsponse  to 
the  query  shown  in  Figur°  3.139. 

KE   —  MSLGUN      <cr> 

VR  --    " Ecth  Missile  and  Gun  Systems" 

This  input  would  initiate  a  display  on  the  graphics  mcnitor 
showing  the  coverage  areas  for  both  the  missile  (shown  in 
"greer")  ,  and  the  gun  systems  (shown  in  "red")  for  the 
battle  group.  Refer  to  Table  XI  and  Table  XII  for  a 
summary  cf  the  ranges  associated  with  the  various  missile 
and   gun  systems   available.     Additionally,    the  type  of 
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installed    systems      would   be    shown    ,         by   ship  name,         on   the 
terminal   screen.  The     format   of  this   display      is    shewn   in 

Figure   3.143. 


*    BATTLE    GEOUP    MISSILE    AND    GUN    SYSTEMS    * 
UNIT    NAME  MISSILE    SYSTEM  GUN    SYSTEM 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure   3. 143        Force    Missile   and   Gun   Systems. 


Following  these  displays,  you  will  be  able  to  enlarge  the 
plot,  and  display  th€  threat  sector  and  cartesian  coordinate 
axes,  as  well  as  experiment  with  changing  a  unit's  position. 
The  queries  and  associated  responses,  required  to  initiate 
these  features,  are  shown  in  succeeding  sections  of  this 
module. 

d.      Display    cf  Force   ASW    Weapons   System   Coverages 

If  you  desire  to  display  the  force  ASW  weapens 
systems,  ycu  would  enter  the  following,  in  response  to  the 
guery    shewn   in    Figure  3.139. 

KB      —  ASW  <cr> 

VR      --      "ASW    Weapons   Systems" 

This  response  will  generate  a  display  on  the  graphics 
monitor  which  shows  the  battle  group  units  in  their  relative 
positions,      and    identified    by   name.  There   are   three    capa- 

bilities       addressed      in        the        ASW     display,  helicopter 

(LAMPS/HS)  ,  ASROC/SUEEOC,  and  torpedo.  Each  ship  will  have 
around    it   a   circle    representative   of   her   respective 
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capability.  The      helicopter   ranges  are    shown      in   "green," 

the  ASROC/SOBROC  ranges  in  "yellow,"  and  the  torpedc  ranges 
in  "cyan."  The  information  displayed  in  Table  XIII  shows 
the    system    ranges  associated   with  these    systems. 


TABLE    XIII 
DSS   ASW    System  Ranges 


System 

Range  (nm) 

Helicopter    (LAMPS/HS) 

100.0 

A5ROC 
SDBROC 

4.8 
25.0 

EK46    Torpedo 
MK48    Torpedo 

2.0 
10.0 

Additionally,  on  the  terminal  screen  the  unit  names,  and 
their  associated  helicopter,  ASW-Rocket ,  and  torpedo  capa- 
bilities are  presented.  The  format  for  this  display  is 
show    in    figure    3.144. 


*    BATTLE    GROUP     ASW    WEAPONS    SYSTEMS    * 
□SIT    NAME  HEIICOPTEB  ASW-ROCKET  TORPEDO 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure    3.144        Battle  Group   ISW    Weapons   Capabilities. 
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The  display  would  shew  YES/NO  for  helicopter,  indicating 
that    there      is    an      ASW  helicopter      onboard   that      unit.  It 

would  additionally  indicate  the  type  of  ASW-Rocket 
(ASROC/SUEROQ  ,  and  type  cf  torpedo  which  are  onboard  the 
unit.  Following  this  display,  you  would  be  able  to  enlarge 
the  plot  and  display  the  threat  sector  and  cartesian  coordi- 
nate axes,  as  well  as  experiment  with  changing  the  position 
of   a    unit.  The  gueries   and   responses    for  initiating    these 

features  are  shown    in   succeeding   sections   of   this    module. 

e.      Display    cf  Force   HARPOON   Weapons   Coverages 

If  you  desired  to  display  the  coverage  area  of 
the  force  HARPOON  weapons,  then  you  would  enter  the 
following   response    tc  the  guery   shown    in   Figure    3.139. 

KB       —  HARPOON         <cr> 

VR      —      "HARPOON   Weapons" 

As  a  result  of  this  input,  you  would  see  a  display  or.  the 
graphics  monitor  of  the  battle  group  units  in  their  relative 
positions,        and      identified   by      name.  Surrounding      each 

HARPOCN  ship  would  be  a  circle  (radius  60.0  nm). 
Additionally,  the  names  cf  all  battle  group  units  with 
HARPOCN    would      be   presented    on      the   terminal      screen.  The 

heading   for   this  display  is    shown    in    Figure   3.145. 


*    BATTIZ    GROUP    HARPOON    UNITS    * 

<ship  name> 
<ship  name> 
<ship    name> 

***    PRESS    RETURN    TO    CONTINUE    *** 


Figure    3.145        Battle   Group   HARPOON    Units. 
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Following  the  display  of  this  information,  you 
will  fce  able  to  enlarge  the  plot,  and  display  the  threat 
sector  and  cartesian  coordinate  axes,  as  well  as  experiment 
with      changing   the      position      cf   a      unit.  The    query      and 

response  sequences  for  initiating  these  features  are 
discussed   in  succeeding   sections   of   this   module. 

f.      Display   cf   Force  TCMAHAWK   weapons   Coverage 

If  you  desired  to  display  the  force  TOMAHAWK 
weapons  system  coverage  areas,  you  would  enter  the  following 
in   response   to   the    query  shown    in   Figure    3.139. 

KB       —  TOMAHAWK         <cr> 

VR      —        "TOMAHAWK    Systems" 

This  input  would  initiate  a  display  on  the  graphics  monitor 
of  the  tattle  group  units  in  their  relative  positions,  and 
identified  by  name.  Those  units  with  a  TOMAHAWK  capability 
would  have  around  trem,  a  circle  of  radius  400.0  nautical 
Biles.  Additionally,    on    the   terminal   screen,      those    units 

would   be   listed      by    name.  The    format    for      this    listing   is 

shown    in    Figure    3.  146. 


* 

BATTIE 

GROUF 

TCMAHAWK 

UNITS 

* 

<ship 
<ship 
<ship 

name> 
name> 
name> 

*** 

._ ,  .  _.  . ,. 

PRESS 

RETURN 

TO 

CONTINUE 

*#* 

Figure    3.14  6        Battle   Group   TOMAHAWK   Units. 

Following     this    display,        you    will      be    able     to 
enlarge    the   plot,   and   display   the   threat   sector    and 
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cartesian  coordinate  axes,  as  well  as  experiment  with 
changing  the  position     of  a    unit.  The      query   and    response 

sequences  associated  with  initiating  these  features  are 
discussed   in  succeeding  sections   of   this   module. 

g.      Display   cf      Force   TOMAHAWK   and      HARPOON   Coverage 
Areas 

If  you  desired  to  display  the  coverage  areas  cf 
BOTH  the  force  TOMAHAWK  and  HARPOON  weapons  systems,  then 
you  would  enter  the  following  in  response  to  the  query  shewn 
in    Figure   3.139. 

KB      —  TOMHAR  <cr> 

VR      —       "Both  TOMAHAWK    and    HARPOON    Systems" 

Resulting  from  this  entry  would  be  a  display  on  the  graphics 
monitor  cf  the  battle  group  units  in  their  relative  posi- 
tions, and  identified  by  name.  Surrounding  those  units 
that  are  capable,  would  be  circles  (TOMAHAWK  in 
"green'VHAREOON  in  "red")  scaled  to  the  ranges  previously 
discussed  for  these  weapons.  Following  this  display,  you 
will  be  able  to  enlarge  the  plot,  and  display  the  threat 
sector  and  cartesian  coordinate  axes,  as  well  as  experiment 
with  changing  the  position  of  a  unit.  The  query  and 
response  sequences  associated  with  initiating  these  feati- 
ures    are   discussed    in   succeeding   sections   of   this    module. 

2  •      Positioning    cf  CAP    Stations 

As  you  saw  in  the  SENSOR  module,  with  the  stationing 
of  an  AZW  aircraft,  if  you  elect  to  display  missiles,  guns, 
or  a  combination  of  the  two,  in  this  module'  you  will  have 
the  opportunity  to  station  two  (2)  CAP  sections.  The  query 
utilized   to   invoke    this   feature   is   shown    in    Figure    3.147. 
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YOU    HAVE    THE    CPPOETUNITY    OF    PLACING    TWO    SECTIONS    OF 
F-14    CAP    IN    SUPPOBT    OF   THE    EATTLE    GROUP. 

???    WOUIB    YOU     LIKE    TO    DO    THIS    ??? 

I        (YES    CR    NO) 


Figure    3.147        Query   —   Stationing  of  CAP. 

The  desired  response  to  this  query  is  "YES"  or  "NO."  If 
you  desired  to  place  a  CAPSTA  in  the  system,  and  enter 
"YES,"  ycu  would  next  be  asked  for  the  position  of  the 
station   for  each      section,      as   applicable.  The      format   of 

both  ths  query  and  response  for  this  position  determination 
is  identical  to  that  in  the  SENSOR  module  for  the  AEW 
station.  The  format      for   the      query   is      shown    in      Figure 

3.  148. 


FOB    CAESTA    NUMBER    1, 

???    KHAT    IS    THE    EEARING     AND    RANGE    OF    THE    STATION 
EEOM    ZZ     ??? 

(ENTEB    AS    BEARING    IN    DEGREES    TRUE,     RANGE    IN    NAUTICAL 
MILES.         E.G.     BBB    BRR) 


Figuie    3.148        Query  —   Determination   of   CAPSTA    Position. 


Notice   that  the  query  addresses      CAPSTA   number    1.  If   you 

elect      to   have      two    CAPSTAS,        the   query      would   reflect      the 
rumber   of   the   second    station.  If   you   desired    to    position 

CAPSTA   nr.  1    340    degrees      true,       100    nautical      miles   from 

"ZZr"    ycu   wculd    make    the   entry   shown    in    Figure  3.149    . 
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1 

I 

KE      —  340    100  <cr   > 

VR      —     "Three"    "Four"    "Zero"    "Space"    "One"    "Zero" 
"Zero"    "Carriage    Beturn" 


Figure  3. 149        Specification  of   CiPSTA. 

If  an  error  were  to  occur  while  making  this  entry,  you  woulfl 
be  so  advised,  and  given  the  opportunity  to  reenter  the 
correct   position.  After    the      position    of     the    first      CAP 

staticn  has  been  entered,  you  will  be  asked  if  you  desire  to 
employ   the    second      station.  The   format    for     this   query   is 

shown    in   Figure    3.150. 


??    WOULD    YOU    LIKE    TO    EMPLOY    THE    SECOND    CAP    STATION    ??  i 

I 
(YES    CR    NO)  ! 


Figure    3.150        Query   —   Second   CAP    Station. 


The    desired     response  is      "YES"  or      "NO."        If      you    indicate 

that    ycu      want    another      CAPSTA,  and      enter   "YES,"      you   will 

sequence      through      the   position  determination      query      shewn 

above.           If     you   enter   "NO,",  you      will   cycle    to      the   next 
feature   cf    this    module. 

3 .      Enlarging   the   Size    cf    the   W  ea Don s    Coverage    Display 

The   initial    size  of    the   graphics      plot  is    1000    nm   by 
950    nm.  In   some   cases,      this   scale   is   inadequate   to    accu- 

rately   view   the      coverages    of    the   displayed      weapons   system. 


21  1 


In  order  to  afford  ycu  the  opportunity  to  change  this  scale, 
the   query  shown    in    Figure   3.125   is   presented.  You    will   be 

able    to     enlarge  the    plot      up   to      five    (5)      times.  For   a 

review  of  the  pragmatics  of  responding  to  this  query,  refer 
to  the  appropriate  topic  in  the  SENSOR  MODULE  OPERATIONS 
section. 

**•      Eisplay    of      T treat    Sector     and   Cartesian      Coordinate 
Grid 

Cnce  the  module  option  you  have  selected  has  been 
displayed,  and  you  have  adjusted  the  scale  as  required,  you 
will  be  will  be  offered  the  option  of  displaying  the  threat 
sector   and   cartesian    coordinate      grid.  The    query/response 

sequences  for  initiating  these  features  from  this  module, 
are   the    same  as    you   exercised    from   the   SENSOR   module.  The 

composition  of  these  queries  are  shown  in  Figures  3.128  and 
3.129.  Figure   3.151,      A    repeat   of    Figure   3.128,      is    shewn 

below . 


Ill    WCULD   YOU    LIKE    TO    SEE    EITHER    OF    THE    FOLLOWING    111 

1  —    VERTICAL    PLOT    AXES 

2  —   THREAT    SECTOR 

I        (ENTER    TEE    APFROPETATE    NUMBER    OR    PRESS    "CARRIAGE    RE- 
TURN"   TO   CONTINUE) 


Figure    3,151        Query  -    Threat  Sector/Cartesian   Grid. 

As  you  have  seen  in  the  discussion  from  SENSOR 
module  operations,  the  desired  response  to  this  query  is 
straightfoward .  Remember    also,      that   you   can   only    display 

the    Vertical  Plot   axes  once.        They   will,    in   fact,    remain   on 
the    screen   once      selected,       until   you    select      another    module 
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option.  Should   you  indicate   display      of   the  VERTICAL   PLOT 

AXES,  anc  they  are  already  displayed,  then  you  will  see  the 
following. 

YOU    HAVE    ALREADY    DISPLAYED    THE    VERTICAL    PLOT    AXES 

***    PRESS    RETURN    TO    CONTINUE    *** 

When  you  continue,  you  will  be  presented  with  the  query 
shown  in  Figure  3.129,  and  essentially,  your  only  available 
options  are  to  display/change  the  threat  sector,  or 
continue.  Should    an   error   occur      in   making   this   response, 

the    fcllcwing    will    be   presented. 

PLEASE  EEENTER  THE  COMMAND  EXACTLY  AS  SHOWN  IN  THE 
SELECTIONS    LIST. 

The  guery  will  again  be  displayed  and  ycu  can  reenter  your 
response.  To      reiterate,      a      more   in-depth      discussion   of 

these  features  is  conducted  in  the  appropriate  topics  of  the 
SENSCB    MCCDLE   OPERATIONS    section. 

5 .      Expermier.tallv  Changing  the    Position   of    a    Unit 

The  final  capability  of  this  module  is  the  experi- 
mentation with  changing  the  position  of  a  unit.  The  intent 
cf  this  feature  is  that  the  user  can  observe  the  effects  on 
the    weapons  systems1    coverage   by    making    such   a   change.  As 

you  have  seen  in  the  SENSOR  module  discussion  of  this  capa- 
bility, you  can  experiment  with  up  to  ten  (10)  units.  The 
number  of  times  you  neve  a  unit  is  unrestricted.  With  each 
move,  ycu  will  be  allowed  to  make  that  new  position  perma- 
nent, or  retain  the  original  position  of  the  unit  within  the 
database.  On  the  graphics  monitor,  you  will  see  the 
current  weapons  system  display  with  which  you  are  working. 
The  refreshed  display,  however,  will  show  the  unit  you 
selected   for  a      position  change   in   her   new      position,      and  a 
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reference  line  back  to  the  current  database  position  for 
that    unit.  Additionally,      on   the      terminal   screen    will   be 

displayed  the  respective  weapon  system  onboard  that  unit. 
The  query  for  initiating  this  feature  is  shown  in  Figure 
3.  152. 
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???    EC    YCU    DESIRE    TC    EXPERIMENT    WITH    THE    COVERAGES    BY 
MOVING    A    UNIT    ??? 

(YES/NO) 


Figure   3.152        Cuery  -    Changing  a   Onitfs  Position. 


This  query  is  displayed  in  conjunction  with  the  queries  for 
threat      sector/cartesian   coordinate      grid    displays.  Each 

time  ycu  move  a  unit,  you  will  then  see  the  query  shown  in 
Figure  3.151  or  3.129.  The  system  will  cycle  through  these 
sequences  twice  before  you  finish  with  the  current  display 
of    ycur   selected   weapons  system.  The   desired   response   to 

the  query  shown  in  Figure  3.152  is  the  YES/NO  input  we  have 
seen    before.  If    ycu  enter    "YES,"      then    you  will      next    be 

queried  regarding  the  name  of  the  unit  you  desire  to  move, 
followed   by  the    new    position   of   that    unit.  The    pragmatics 

of  the  cuery/re sponse  sequences  associated  with  this  capa- 
bility are  discussed  in  detail  under  that  appropriate  topics 
cf      the      SENSOR      module   Operations      section.  Should      you 

attempt  to  move  more  than  ten  (10)  units,  the  warning  shown 
below    will    be  presented. 

YOU  HAVE  ALREADY  MOVED  THE  MAXIMUM  ALLOWABLE  NUMBER  OF  10 
UNITS 
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If   your    response  to   the      query   shown   in   Figure    3.152 
was    "NO,"   one      of   two  actions   would   be   taken.  If   this   is 

the  first  presentation  of  the  query,  you  will  be  cycled  to 
the    query      shown   in    Figure    3.151.  If   this   is      the    second 

time  the  query  has  been  presented,  the  system  will  determine 
that  ycu  are  finished  with  the  display  of  the  current  capa- 
bility, and  you  will  see  the  following  displayed  on  the 
scr  e  e  n . 

**    CACTICN    **    THE    DISPLAYED    GRAPHICS    WILL    BE    ERASED    WHEN 

YOU    CCNTINOE 

***    PRESS    RETURN    TO    CONTINUE    *** 

The  current  graphics  display,  with  all  of  the  features  you 
have  initiated,  will  remain  on  the  graphics  monitor  until 
you  continue.  Once  you  continue,  you  will  be  cycled  to  the 
module      menu  shown      in      Figure   3.139.  If      you   desire     to 

display  another  weapons  systam  capability,  enter  the  appro- 
priate option.  If  ycu  desire  to  return  to  the  MAIN  module, 
enter  "EXIT."  You  must  return  to  the  MAIN  module  in  crder 
to   access  another  DSS   module. 
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APPENDIX    A 
VOICE    RECOGNITION    COMMAND    FORMATS 

This  appendix  contains  the  foundation  of  the  voice 
architecture  supporting  the  Decision  Support  System. 
Unique  to  the  format  structure  of  discrete  speech  voice 
recognition  primitives,  the  information  contained  in  Table 
XIV  constitutes  the  "prompts,"  voice  command  strings  (when 
different  from  the  "prompts")  and  the  "output  string"  asso- 
ciated with  the  entries.  This  information  is  recorded  on 
the  tape  accompanying  this  Thesis.  A  brief  explanation  of 
the  procedures  for  creating  a  voice  tape  are  appropriate  at 
this    pcint. 

The  Treshold  Technology  1-600  equipment  utilized  for 
this  thesis  requires  three  segments  for  each  anticipated 
voice   cctrmand.       The    details    of   "training"    the   machine    for 

your    voice   can      be    obtained   from   the      Man-Machine   Interface 
Laboratory,    at    NFS.  Basically,      the   three   steps    to    estab- 

lishment of  a  voice  command  are  to  first,  determine  a 
"prompt,"  second,  input  the  "output"  string  associated  with 
that  "prompt"  (maximum  length  for  an  "output"  string  is  16 
characters)  ,  and  third,  "training"  the  machine  with  a  vcice 
command      to   which      y  cu      want      the   "output."      equated.  The 

"prompt"  and  "output"  are  referenced  by  a  three  digit  refer- 
ence number  (000  -  256).  This  equipment  has  a  maximum 
capacity  for  256  commands.  Once  you  have  input  the 
"prompt"  and  "output,"  the  "training"  consists  of  speaking 
the  phrase  you  desire  so  that  the  equipment  can  establish  a 
reference  fcr  that  particular  voice  pattern.  Once  this 
"training"  has  been  completed,  the  machine  will  cause  the 
appropriate  "output"  to  be  generated  each  time  that  command 
is    made.        Cnce    you   have   completed  the   sequencing    of   command 
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establishment,  your  complete  command  vocabulary  can  be 
recorded     on  tape.  Each    subsequent      time      you   desire     to 

utilize  the  voice  commands,  you  can  load  your  voice  command 
patterns  into  the  T-6C0,  and  it  can  then  act  as  a  keyboard 
for   entry   of      your    responses.  This   overly     simplifies   the 

mechanics  cf  creating  the  voice  commands,  however,  the 
intent    was   to   give    you  a   general    feel    for   the   process. 

A  primary  functicn  of  this  appendix  is  to  serve  as  a 
reference  from  which  the  acceptable  voice  commands  for  the 
system      can   be      obtained.  If      there   is      no   voice      command 

string  indicated,  the  "prompt"  serves  as  the  command  string. 
With  respect  to  the  listings  for  the  ships,  by  inclusion 
herein,  the  ship  is  verified  to  be  residing  in  the  Master 
Database    for  the   Decision   Support   System. 
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